Certificate Services

Certificate Services provides customizable services for issuing and managing certificates that are used in software security systems that employ public key technology. Certificate Services is available on computers running XOX; XOX; and XOX.

  • Before deploying certification authorities and a public key infrastructure, see Checklist: Creating a certification hierarchy with an offline root certification authority.
  • Before configuring certification authorities and clients for certificate autoenrollment, see Checklist: Configuring certificate autoenrollment.
  • Before removing a deployed certification authority from your enterprise, see Checklist: Decommissioning a certification authority.
  • For tips about using Certificate Services, see Best practices.
  • For help with specific tasks, see How to.
  • For general background information, see Concepts.
  • For problem-solving instructions, see Troubleshooting.


Checklist: Creating a certification hierarchy with an offline root certification authority

This checklist is provided for the cases where the root certification authority (CA) is not connected to your organization's network. You might choose to have an isolated, offline root CA for security reasons in order to protect it from possible attacks by intruders by way of the network.

Administrators of public key infrastructures (PKIs) must provide certificate verifiers with online certificate revocation checking. This checklist helps them to set up functional certificate revocation checking for certificates issued by an offline root CA.

Step | Reference
Review concepts |
Review public key infrastructure concepts. | Public key infrastructure
Review certificates concepts. | Certificates concepts
Review concepts about certification authorities. | Certificate Services concepts
Set up the offline root certification authority |
Plan the certification hierarchy. | Certification authority hierarchies
Set up a server that runs Windows that you will use for the root certification authority. The server should not be a member of any domain, should be disconnected from the network, and should be physically secure. The server should also have Internet Information Services (IIS) installed as part of the setup process, although this is not required. | Checklist: Performing a new installation
Plan the renewal strategy you are going to use for the root certification authority | Renewing certification authorities
Log on to the server as the administrator and install Certificate Services to create a stand-alone root certification authority. | To install a stand-alone root certification authority
Prepare the offline root certification authority to issue certificates |
On the new root CA, change the default action upon receipt of a certificate request so that all requested certificates are set to pending. This is to ensure only authorized requests are issued by the top-level CA. | To set the default action upon receipt of a certificate request
On the new root CA, change the URL location of the certificate revocation list (CRL) distribution point to a location of your choice that is accessible to all users in you organization's network. It is possible to enter multiple URLs. It is necessary to do this because the offline root CA's default CRL Distribution Points (CDPs) are not accessible to users on the network and, if they are left unchanged, certificate revocation checking will fail. | To specify CRL distribution points in issued certificates
On the new root CA, change the URL location of the authority information access (AIA) distribution points to a location of your choice that is accessible to all users in you organization's network. It is possible to enter multiple URLs. It is necessary to do this because the offline root CA's default AIA points are not accessible to users on the network and, if they are left unchanged, certificate chain verification will fail. | To specify CA certificate access points in issued certificates
Schedule the publication of the certificate revocation list. Since publishing the CRL from an offline CA has the administrative overhead of having to physically copy the CRL to a server on the network, you may want to have a lengthy validity period. | To schedule the publication of the certificate revocation list
On the root certification authority, publish the certificate revocation list. | To manually publish the certificate revocation list
In Windows Explorer on the root CA, locate the certificate revocation list you just published. The CRL's default location is: \systemroot\system32\CertSrv\CertEnroll\CAname.crl Right-click the CRL file and send it to a drive that has portable storage media. |
Retrieve the certification authority's certificate and save it to a drive that has portable storage media. | To retrieve a certification authority certificate
Copy the certificate revocation list file and the CA certificate to every URL location that you specified as a CRL distribution point in the root CA's policy settings. |
Copy the CA certificate file to every URL location that you specified as an authority information access distribution point in the root CA's policy settings. |
If you are deploying your PKI in an Active Directory directory service environment |
Publish the root certificate to the enterprise root store and add the certificate to the customary Authority Information Access (AIA) points in the directory. You need to use certutil.exe. You can also use this command to put the CA certificate from a third party root CA into Active Directory. | At a command prompt, type: certutil -dspublish -f .Crt File Name RootCA
Publish the CRL to the customary location in Active Directory. To do this, use certutil.exe. You can also use this command to put the CRL from a third-party root CA into Active Directory. | From the command line, type: certutil -dspublish -f .Crl File Name
To create a online certification authority that is subordinate to an offline root certification authority |
Set up a server running Windows to use for the subordinate certification authority | Checklist: Performing a new installation
Install subordinate certification authorities, as required by your planned certification hierarchy. These can be stand-alone certification authorities or, if you are using Active Directory, enterprise certification authorities. During setup for each subordinate CA, choose to save the CA certificate request to a file, which will be a PKCS #10 request. | To install a stand-alone subordinate certification authority; To install an enterprise subordinate certification authority
Copy the CA certificate request file from the subordinate certification authority to some portable storage media. Take the CA certificate request to the root certification authority. |
Using the Certificates Microsoft Management Console (MMC) on the offline CA, submit the certificate request (requestfilename) to the CA and copy the new certificate (newcertname) to the portable storage media. | Manage certificates for a computer
Take the portable storage media back to the subordinate certification authority. In Windows Explorer, locate the certificate and certification path files you just copied, then right-click each file and choose Install Certificate. Have the Certificate Import Wizard automatically place the certificates in stores based on the type of certificate. | To import a certificate


Checklist: Configuring certificate autoenrollment

Step | Reference
Install and configure an enterprise certification authority (CA) | To install an enterprise root certification authority; To install an enterprise subordinate certification authority
Create a new certificate template | To create a new certificate template
Configure the certificate template to provide the intended functionality for the certificate | To modify a certificate template
Configure the certificate template to allow autoenrollment | Planning for autoenrollment deployment
Grant Enroll and Autoenroll permissions for the certificate template to intended users | To allow subjects to request a certificate that is based on the template
Configure the certification authority to issue certificates based on the template | To add a certificate template to a certification authority
Configure Active Directory directory service users to request certificates with autoenrollment | Certificate Services example implementation: Establishing autoenrollment for user certificates
(Optional) Retrieve updated Group Policy information before scheduled replication occurs | Gpupdate

Notes

  • XOX or XOX is required to configure version 2 certificate templates for autoenrollment requests. However, autoenrollment manages certificates or pending certificate requests that are based on any version of certificate template.
  • For more information on certificate autoenrollment in XOX and the Windows Server 2003 family, see "Certificate Autoenrollment in XOX" on the Microsoft Web site.(http://www.microsoft.com/)


Checklist: Decommissioning a certification authority

Once a certification authority (CA) is configured and operating in an enterprise, it becomes an important security resource. The certification authority is required by existing clients to renew certificates, by new clients to issue certificates, and by users of certificates to verify the trustworthiness of issued certificates. If a CA is removed from an enterprise without following the appropriate procedure, functionality may be impaired and extensive cleanup work may be required to restore clients to functionality.

Step | Reference
Perform a backup of the certification authority (CA) database to ensure recoverability of data at a later date. | To back up a certification authority
Deny all pending certificate requests currently stored on the CA. | To review pending certificate requests
(Optional) Allow the Active Directory directory service to replicate the certificate denials and allow Group Policy to inform the clients that the certificate request is denied. The denied clients are then informed that their request was denied so they can remove the request from their list of outstanding requests. | Replication overview
Revoke the CA's certificate from its parent CA. When revoking the CA certificate, specify the reason as "Cessation of Operation." | To revoke an issued certificate
Manually publish a new certificate revocation list (CRL) to ensure the CRL contains revocation information about the CA that was recently revoked. | To manually publish the certificate revocation list
Uninstall the Certificate Services component. | To uninstall a certification authority
Remove remaining information about this CA from Active Directory. | At a command prompt, type certutil.exe -dsdel CAName and press ENTER, where CAName is the name of the CA you are removing.


Best practices

Plan your public key infrastructure (PKI) before deploying certification authorities (CAs)

  • For information that will assist you with planning a PKI, see Concepts in Certificate Services and Resources in Public Key Infrastructure.

Place database and transaction log files on separate hard drives

  • As in many databases, the certification authority's database is a file on the hard drive. In addition to this file, other files serve as the transaction logs and receive all modifications to the database before the changes are made. Because these files may be accessed frequently and simultaneously, it is best to keep the database and transaction logs on separate hard drives or high-performance disk configurations, such as striped volumes.

    • For more information, see Disk Management.

Keep the root certification authority offline and secure its signing key by hardware and keep it in a vault to minimize potential for key compromise

  • For more information, see Checklist: Creating a certification hierarchy with an offline root certification authority.

If you are going to use a custom policy module for a Microsoft CA, install Certificate Services using stand-alone policy and then replace stand-alone policy with your custom policy

  • Replacing enterprise policy on a certification authority with a custom policy is not supported and will have unpredictable results.

When changing security permissions for the certification authority (CA), always use the Certification Authority snap-in

  • Setting permissions using other tools (such as the Active Directory Sites and Services snap-in) may create problems for users who attempt to access and request certificates from the certification authority.

    For more information, see To set security permissions and delegate control of a certification authority.

Do not issue certificates to users or computers directly from the root certification authority

  • Instead, deploy at least a two-level CA hierarchy comprised of Root-Issuer CAs to provide flexibility and insulate the root certification authority from attempts to compromise its private key by malicious individuals.

    For more information, see Certification authority hierarchies and Establishing a certification hierarchy.

Back up the CA database, the CA certificate, and the CA keys

  • This is essential to protect against the loss of critical data. The CA should be backed up on a regular basis (daily, weekly, monthly), based on the number of certificates issued over the same interval. The more certificates issued, the more frequently you should back up the CA. Full backups should be used to provide the fastest recovery and most reliable data redundancy possible.

    For more information, see Backing up and restoring a certification authority.

Ensure that key lifetimes are long enough to avoid renewal issues

  • A certification authority can issue a certificate with a lifetime equal to or less than the remaining lifetime on its own CA certificate. When the CA certificate has less valid time remaining than the renewal overlap period on issued certificates, the issued certificates are very short lived. In this case, it is possible that clients will be unable to renew their certificates. To avoid this, ensure the CA certificate is renewed long enough before the certificates it issues become short lived.

    For more information, see To renew a root certification authority and To renew a subordinate certification authority.

Review the concepts of security permissions and access control, since enterprise certification authorities issue certificates based on the security permissions of the certificate requester

  • For general information about access control and security permissions in the Windows Server 2003 family, see Access Control. For the procedure to set access control on a CA, see To set security permissions and delegate control of a certification authority.

    For the procedure to set access control on certificate templates, see Controlling enrollment access to certificate templates.

Use Secure Sockets Layer (SSL) when using Web-based certificate enrollment

  • Web enrollment pages provide a simple but insecure method for users to obtain certificates from the CA. The communication between the client and the Web server could be forged or altered in route, compromising security. To mitigate the risk of this occurring, you can use Secure Sockets Layer (SSL) communications between the client and the Web server. This will provide both confidentiality and integrity of the certificate request and response.

    For more information, see Configuring SSL on your server and To set up certification authority Web enrollment support.


How to...

  • Set up a certification authority
  • Administer a certification authority


Set up a certification authority

  • Install an enterprise root certification authority
  • Install an enterprise subordinate certification authority
  • Install a stand-alone root certification authority
  • Install a stand-alone subordinate certification authority
  • Uninstall a certification authority
  • Set up certification authority Web enrollment support
  • Perform qualified subordination


Install an enterprise root certification authority

Microsoft Windows graphic

To install an enterprise root certification authority

  1. Log on as a member of both the Enterprise Admins group and the root domain's Domain Admins group.
  2. If any Windows 2000 enterprise certification authorities (CAs) currently exist or have ever existed in your enterprise, open Certificate Templates and, when prompted to install new certificate templates, click OK.
  3. Open Add or Remove Programs in Control Panel.
  4. Click Add/Remove Windows Components.
  5. In the Windows Components Wizard, select the Certificate Services check box. A dialog box appears to inform you that the computer cannot be renamed and that the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes, and then click Next.
  6. Click Enterprise root CA.
  7. (Optional) Select the Use custom settings to generate the key pair and CA certificate check box, and then click Next to specify the following.
    To set this | Do this
    Cryptographic service provider (CSP) | In CSP, click the CSP that you want to use. The default is the Microsoft Strong Cryptographic Provider. Certificate Services does support third party CSPs, but you must refer to the CSP vendor's documentation for information about using their CSP with Certificate Services.
    Hash algorithm | In Hash algorithm, click the hash algorithm you want to use. The default is SHA-1.
    Use an existing key Select the Use existing key check box, click Import, and then, in Open PFX File, type the file name and password of the public and private key pair. This is helpful if you are relocating or restoring a previously installed certification authority (CA). Note that, when using an existing key, a new certificate is generated.

    Important

    • Be sure that you select an existing key that you know to be uncompromised and trustworthy. Using a key that may be compromised or untrusted could cause this CA and all its issued certificates to be insecure.
    Key length | In Key length, type or select a key length. The default key length using the Microsoft Strong Cryptographic Provider is 2048 bits. Default key lengths for other CSPs vary. In general, the longer the key length, the more secure the key is. Also, longer key lengths require more system resources for operations such as signing, encryption, and chain verification. For a root CA, you should use a key length of at least 2048 bits. This option is not available if you use existing keys.
    Allow this CSP to interact with the desktop | Select the Allow this CSP to interact with the desktop check box. Without this option, system services cannot interact with the desktop of the user who is currently logged on.
    Import | Click Import. This imports an existing key in the PKCS #12 PFX format.
    View certificate | Click View certificate. This allows you to view the certificate that you select or generate during installation.
    When you are done, click Next.
  8. In Common name for this CA, type the common name of the certification authority.
  9. In Validity period, specify the validity duration for the root CA and click Next.
  10. Specify the storage locations of the certificate database, the certificate database log, and the shared folder and click Next.
  11. If Internet Information Services (IIS) is running, you will see a request to stop the service before proceeding with the installation and click OK.
  12. If prompted, type the path to the Certificate Services installation files.

Notes

  • The preliminary information that is supplied during setup, such as the name of the certification authority, cannot be changed after the CA setup is complete.
  • Before installing a certification authority, you should configure the computer's domain settings first, such as joining a domain or promoting a server to a domain controller. These settings cannot be changed once the certification authority is installed.
  • If Active Server Pages are not enabled through Internet Information Services, you will be prompted to activate them. The Web interface for the certification authority requires running Active Server Pages.
  • The enterprise root CA selection requires that the host computer be a member of a domain and that it use the Active Directory directory service. The administrator who is installing an enterprise CA must have Write permission to Active Directory.
  • If you have Write permission to Active Directory, then specifying the shared folder is optional, and is not typically done for enterprise certification authorities.
  • The validity duration you choose for the CA will determine when the CA "expires." For information about renewing CAs, see Related Topics.
  • If you installed the enterprise certification authority as an Enterprise Admin or delegated user, then you must use the Enterprise Admin or delegated user account when you uninstall the enterprise certification authority.
  • XOX
  • Once the certification authority is installed, add certificate templates to the certification authority and configure the certification authority to allow subjects to request a certificate that is based on a template. For more information, see Related Topics.
  • For more information on any installation settings, see Related Topics.

Related Topics


Install an enterprise subordinate certification authority

Microsoft Windows graphic

To install an enterprise subordinate certification authority

  1. Log on as a member of both the Enterprise Admins group and the root domain's Domain Admins group.
  2. If any Windows 2000 enterprise certification authorities (CAs) currently exist or have ever existed in your enterprise, open Certificate Templates and when prompted to install new certificate templates, click OK.
  3. Open Add or Remove Programs in Control Panel.
  4. Click Add/Remove Windows Components.
  5. In the Windows Components Wizard, select the Certificate Services check box. A dialog box appears to inform you that the computer cannot be renamed and that the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes, and then click Next.
  6. Click Enterprise subordinate CA.
  7. (Optional) Select the Use custom settings to generate the key pair and CA certificate check box, and then click Next to specify the following.
    To set this | Do this
    Cryptographic service provider (CSP) | In CSP, click the CSP that you want to use. The default is the Microsoft Strong Cryptographic Provider. Certificate Services does support third party CSPs, but you must refer to the CSP vendor's documentation for information about using their CSP with Certificate Services.
    Hash algorithm | In Hash algorithm, click the hash algorithm you want to use. The default is SHA-1.
    Use an existing key Select the Use existing key check box, click Import, and then, in Open PFX File, type the file name and password of the public and private key pair. This is helpful if you are relocating or restoring a previously installed certification authority (CA). Note that, when using an existing key, a new certificate is generated.

    Important

    • Be sure that you select an existing key that you know to be uncompromised and trustworthy. Using a key that may be compromised or untrusted could cause this CA and all its issued certificates to be insecure.
    Key length | In Key length, type or select a key length. The default key length using the Microsoft Strong Cryptographic Provider is 2048 bits. Default key lengths for other CSPs vary. In general, the longer the key length, the more secure the key is. Also, longer key lengths require more system resources for operations such as signing, encryption, and chain verification. For a root CA, you should use a key length of at least 2048 bits. This option is not available if you use existing keys.
    Allow this CSP to interact with the desktop | Select the Allow this CSP to interact with the desktop check box. Without this option, system services cannot interact with the desktop of the user who is currently logged on.
    Import | Click Import. This imports an existing key in the PKCS #12 PFX format.
    View certificate | Click View certificate. This allows you to view the certificate that you select or generate during installation.
    When you are done, click Next.
  8. Type the common name (CN) of the CA and click Next.
  9. Specify the storage locations of the certificate database, the certificate database log, and the shared folder. Click Next.
  10. Obtain the certificate for the subordinate CA. For instructions on how to do this, see Notes.
  11. If Internet Information Services is running, the system will request that you stop the service before proceeding with the installation. Click OK.
  12. If prompted, type the path to the Certificate Services installation files.
  13. Once the certification authority is installed, add certificate templates to the certification authority and configure the certification authority to allow subjects to request a certificate that is based on a template.

    For more information, see Related Topics.

Notes

  • The name of the CA and the other initial information cannot be changed after the CA setup is complete.
  • If Active Server Pages are not enabled through Internet Information Services, you will be prompted to activate them. The Web interface for the certification authority requires running Active Server Pages.
  • To obtain the certificate for a subordinate CA, you must submit a certificate request to a parent CA. The procedure for doing so differs depending on whether the parent CA is available online.
    • If a parent CA is available online:
      1. Click Send the request directly to a CA already on the network.
      2. In Computer Name, type the name of the computer on which the parent CA is installed.
      3. In Parent CA, click the name of the parent CA.
    • If a parent CA is not available online:
      1. Click Save the request to a file.
      2. In Request file, type the path and file name of the file that will store the request.
      3. Obtain this subordinate CA's certificate from the parent CA.

        The procedure for doing this will be unique to the parent CA. At a minimum, the parent CA should provide a file containing the subordinate CA's newly issued certificate and, preferably, its full certification path. For the procedure to submit a certificate request using a file to a XOX; XOX; or XOX CA, see Related Topics.

        If you get a subordinate CA certificate that does not include the full certification path, the new subordinate CA you are installing must be able to build a valid CA chain when it starts. Thus you must install the parent CA's certificate in the Intermediate Certification Authorities certificate store of the computer (if the parent CA is not a root CA), as well as the certificates of any other intermediate CA in the chain, and you must install the certificate of the root CA in the chain into the Trusted Root Certification Authorities store. These certificates should be installed in the certificate store before you install the CA certificate on the subordinate CA you have just set up.

      4. Open Certification Authority.
      5. In the console tree, click the name of the CA.

        Where?

        • Certification Authority (Computer)
        • CA name
      6. On the Action menu, point to All Tasks, and then click Install CA Certificate.
      7. Locate the certificate file received from the parent certification authority, click this file, and then click Open.
      8. If the root CA is untrusted, click OK to trust the root CA's certificate.
      9. Once the certificate is installed, start Certificate Services.
      XOX
  • The enterprise subordinate CA selection requires that the host computer be a member of a domain and that it use the Active Directory directory service. The administrator who is installing an enterprise CA must have Write permission to Active Directory.
  • If you have Write permission to Active Directory, then specifying the shared folder is optional, and is not typically done for enterprise CAs.
  • To open Certification Authority, click Start, point to Programs, point to Administrative Tools, and then click Certification Authority.
  • If you installed the enterprise subordinate certification authority as an Enterprise Admin or delegated user, then you must use the Enterprise Admin or delegated user account when you uninstall the enterprise subordinate certification authority.
  • XOX

Related Topics


Install a stand-alone root certification authority

Microsoft Windows graphic

To install a stand-alone root certification authority

  1. Log on to the system as an Administrator, or if you have the Active Directory directory service, log on to the system as a Domain Administrator.
  2. Click Start, point to Settings, and then click Control Panel.
  3. Double-click Add or Remove Programs and then click Add/Remove Windows Components.
  4. In the Windows Components Wizard, select the Certificate Services check box. A dialog box appears to inform you that the computer cannot be renamed and that the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes, and then click Next.
  5. Click Stand-alone root CA.
  6. (Optional) Select the Use custom settings to generate the key pair and CA certificate check box, and then click Next to specify the following.
    To set this | Do this
    Cryptographic service provider (CSP) | In CSP, click the CSP that you want to use. The default is the Microsoft Strong Cryptographic Provider. Certificate Services does support third party CSPs, but you must refer to the CSP vendor's documentation for information about using their CSP with Certificate Services.
    Hash algorithm | In Hash algorithm, click the hash algorithm you want to use. The default is SHA-1.
    Use an existing key Select the Use existing key check box, click Import, and then, in Open PFX File, type the file name and password of the public and private key pair. This is helpful if you are relocating or restoring a previously installed certification authority (CA). Note that, when using an existing key, a new certificate is generated.

    Important

    • Be sure that you select an existing key that you know to be uncompromised and trustworthy. Using a key that may be compromised or untrusted could cause this CA and all its issued certificates to be insecure.
    Key length | In Key length, type or select a key length. The default key length using the Microsoft Strong Cryptographic Provider is 2048 bits. Default key lengths for other CSPs vary. In general, the longer the key length, the more secure the key is. Also, longer key lengths require more system resources for operations such as signing, encryption, and chain verification. For a root CA, you should use a key length of at least 2048 bits. This option is not available if you use existing keys.
    Allow this CSP to interact with the desktop | Select the Allow this CSP to interact with the desktop check box. Without this option, system services cannot interact with the desktop of the user who is currently logged on.
    Import | Click Import. This imports an existing key in the PKCS #12 PFX format.
    View certificate | Click View certificate. This allows you to view the certificate that you select or generate during installation.
    When you are done, click Next.
  7. Type the common name of the certification authority. None of this information can be changed after the CA setup is complete.
  8. In Validity period, specify the validity duration for the root CA. See the note below about considerations when setting this value. Click Next.
  9. Specify the storage locations of the certificate database, the certificate database log, and the shared folder. Click Next.
  10. If Internet Information Services (IIS) is running, you will receive a request to stop the service before proceeding with the installation. Click OK.
  11. If prompted, type the path to the Certificate Services installation files.

Notes

  • XOX
  • If Active Directory is available and you have Write permission to Active Directory, then specifying the shared folder is optional.
  • If Active Server Pages are not enabled through Internet Information Services, you will be prompted to activate them. The Web interface for the certification authority requires running Active Server Pages.
  • The validity duration you choose for the CA will determine when the CA "expires." For information about renewing CAs, see Related Topics.
  • XOX
  • For more information on any installation settings, see Related Topics.

Related Topics


Install a stand-alone subordinate certification authority

Microsoft Windows graphic

To install a stand-alone subordinate certification authority

  1. Log on to the system as an Administrator, or if you have the Active Directory directory service, log on to the system as a Domain Administrator.
  2. Open Add or Remove Programs in Control Panel.
  3. Click Add/Remove Windows Components.
  4. In the Windows Components Wizard, select the Certificate Services check box. A dialog box appears to inform you that the computer cannot be renamed and that the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes, and then click Next.
  5. Click Stand-alone subordinate CA.
  6. (Optional) Select the Use custom settings to generate the key pair and CA certificate check box, and then click Next to specify the following.
    To set this | Do this
    Cryptographic service provider (CSP) | In CSP, click the CSP that you want to use. The default is the Microsoft Strong Cryptographic Provider. Certificate Services does support third party CSPs, but you must refer to the CSP vendor's documentation for information about using their CSP with Certificate Services.
    Hash algorithm | In Hash algorithm, click the hash algorithm you want to use. The default is SHA-1.
    Use an existing key Select the Use existing key check box, click Import, and then, in Open PFX File, type the file name and password of the public and private key pair. This is helpful if you are relocating or restoring a previously installed certification authority (CA). Note that, when using an existing key, a new certificate is generated.

    Important

    • Be sure that you select an existing key that you know to be uncompromised and trustworthy. Using a key that may be compromised or untrusted could cause this CA and all its issued certificates to be insecure.
    Key length | In Key length, type or select a key length. The default key length using the Microsoft Strong Cryptographic Provider is 2048 bits. Default key lengths for other CSPs vary. In general, the longer the key length, the more secure the key is. Also, longer key lengths require more system resources for operations such as signing, encryption, and chain verification. For a root CA, you should use a key length of at least 2048 bits. This option is not available if you use existing keys.
    Allow this CSP to interact with the desktop | Select the Allow this CSP to interact with the desktop check box. Without this option, system services cannot interact with the desktop of the user who is currently logged on.
    Import | Click Import. This imports an existing key in the PKCS #12 PFX format.
    View certificate | Click View certificate. This allows you to view the certificate that you select or generate during installation.
    When you are done, click Next.
  7. Type in the common name (CN) and distinguished name suffix of the CA. None of this information can be changed after the CA setup is complete. Click Next.
  8. Specify the storage locations of the certificate database, the certificate database log, and the shared folder. Click Next.
  9. Obtain the certificate for the subordinate CA. For instructions on how to do this, see Notes.
  10. If Internet Information Services is running, the system will request that you stop the service before proceeding with the installation. Click OK.
  11. If prompted, type the path to the Certificate Services installation files.

Notes

  • If Active Server Pages (ASP) are not enabled through Internet Information Services, you will be prompted to activate them. The Web interface for the certification authority requires running Active Server Pages.
  • To obtain the certificate for a subordinate CA, you must submit a certificate request to a parent CA. The procedure for doing so differs depending on whether the parent CA is available online.
    • If a parent CA is available online:
      1. Click Send the request directly to a CA already on the network.
      2. In Computer Name, type the name of the computer on which the parent CA is installed.
      3. In Parent CA, click the name of the parent CA.
    • If a parent CA is not available online:
      1. Click Save the request to a file.
      2. In Request file, type the path and file name of the file that will store the request.
      3. Obtain this subordinate CA's certificate from the parent CA.

        The procedure for doing this will be unique to the parent CA. At a minimum, the parent CA should provide a file containing the subordinate CA's newly-issued certificate and, preferably, its full certification path. For the procedure to submit a certificate request using a file to a Microsoft CA, see Related Topics.

        If you get a subordinate CA certificate that does not include the full certification path, the new subordinate CA you are installing must be able to build a valid CA chain when it starts. Because of this, you must install the parent CA's certificate in the Intermediate Certification Authorities certificate store of the computer (if the parent CA is not a root CA), as well as the certificates of any other intermediate CA in the chain, and you must install the certificate of the root CA in the chain into the Trusted Root Certification Authorities store. These certificates should be installed in the certificate store before you install the CA certificate on the subordinate CA you have just set up.

      4. Open Certification Authority.
      5. In the console tree, click the name of the CA.

        Where?

        • Certification Authority (Computer)
        • CA name
      6. On the Action menu, point to All Tasks, and then click Install CA Certificate.
      7. Locate the certificate file received from the parent certification authority, click this file, and then click Open.
      8. If the root CA is untrusted, click OK to trust the root CA's certificate.
      9. Once the certificate is installed, start the Certificate Services service.
  • If Active Directory is available and you have Write permission to Active Directory, then specifying the shared folder is optional.
  • XOX
  • XOX

Related Topics


Uninstall a certification authority

Microsoft Windows graphic

To uninstall a certification authority

  1. Log on to the system as the user who installed the certification authority.
  2. Open Add or Remove Programs in Control Panel.
  3. Click Add/Remove Windows Components.
  4. In the Windows Components Wizard, clear the Certificate Services check box, and then click Next.
  5. If Internet Information Services is running, the system requests that you stop the service before proceeding with the uninstall process. If this happens, click OK.

Notes

  • XOX
  • You should back up the entire server before uninstalling the certification authority (CA).
  • When you uninstall a CA, the following information is left on the server:
    • The CA database
    • The CA public and private keys
    • The CA's certificates in the Personal store
    • The CA's certificates in the shared folder, if a shared folder was specified during Certificate Services setup
    • The CA chain's root certificate in the Trusted Root Certification Authorities store
    • The CA chain's intermediate certificates in the Intermediate Certification Authorities store
    • The CA's certificate revocation list (CRL)

    This information is kept on the server by default, in case you are uninstalling and then reinstalling the CA. For example, you might uninstall and reinstall if you wanted to change a stand-alone CA to an enterprise CA.

  • If you installed the enterprise or enterprise subordinate certification authority as an Enterprise Admin or delegated user, then you must use the Enterprise Admin or delegated user account when you uninstall the certification authority.
  • If you are permanently decommissioning the CA before its expected expiration date, then the CA certificate should be revoked from its parent CA for a certificate revocation reason of "Cease of operation". If the CA is a self-signed root CA, then all of the certificates that have not expired should be revoked and a CRL generated with the same reason. This will indicate that the certificates are no longer valid because the CA has been decommissioned.
  • When uninstalling an enterprise CA, it is important that it be uninstalled properly to ensure that their CA enrollment object is removed from the Active Directory directory service. Failure to do so may result in Active Directory clients continuing to attempt to enroll against that CA. If an enterprise CA cannot be uninstalled normally, Active Directory tools should be used to manually remove the CA objects from Active Directory.

Related Topics


Set up certification authority Web enrollment support

Microsoft Windows graphic

To set up certification authority Web enrollment support

  1. Log on to the system as an Administrator, or if you have the Active Directory directory service, log on to the system as a Domain Administrator.
  2. Open Add or Remove Programs in Control Panel.
  3. Click Add/Remove Windows Components.
  4. In the Windows Components Wizard, select the Certificate Services check box. A dialog box appears to inform you that the computer cannot be renamed and that the computer cannot be joined to or removed from a domain after Certificate Services is installed. Click Yes, and then click Details.
  5. Clear the Certificate Services CA check box, verify that the Certificate Services Web Enrollment Support check box remains selected, click OK, and then click Next.
  6. In Computer Name, type in the name of the computer on which the certification authority (CA) is installed, the CA for which these Web enrollment pages will be used. The name of the CA will appear in the list. Click Next.
  7. If Internet Information Services is running, the system will request that you stop the service before proceeding with the installation. If this happens, click Yes.
  8. If prompted, type in the path to the Certificate Services installation files.

Notes

  • If you installed the CA Web enrollment pages on a computer that is not a CA, the computer account must be trusted for delegation in Active Directory. For more information on trusting a computer for delegation, see Related Topics.
  • CA Web enrollment pages are installed by default when you set up Certificate Services on a server that has Internet Information Services (IIS) installed. This procedure is necessary only if you want to install the CA Web enrollment pages on a server that is separate from the server on which the CA is installed.
  • If you installed the CA Web enrollment pages before installing IIS, the required virtual roots are not created. You can create the virtual roots after installing IIS by typing certutil -vroot at a command prompt. The command certutil -vroot does not install the Web enrollment pages. It creates the IIS virtual roots which point to the Web enrollment pages, CA certificate, CRLs, and enrollment controls (xenroll.dll and scrdenrl.dll).

    For more information on creating or deleting the related set of Certificate Services Web server virtual roots and file shares, see Certutil tasks for configuring a Certification Authority (CA).

  • When you initially install IIS, the service is installed in a highly secure mode. Because IIS only serves static content by default, you must enable features such as ASP. To enable ASP and allow the CA Web enrollment pages to work correctly, see Enabling and Disabling Dynamic Content in Microsoft Internet Information Services.
  • Installation of the Web enrollment pages configures the computer as a registration authority (RA). This computer is also known as a "CA Web proxy" or a "Web enrollment station."
  • XOX

Related Topics


Perform qualified subordination

Microsoft Windows Graphic

To perform qualified subordination

Using the Windows interface

  1. Create the information file for the qualified subordinate certification authority.
  2. Save the information file as CAPolicy.inf in the systemroot directory on the computer where you are installing the qualified subordinate certification authority.

    For more information, see Notes.

  3. Install the qualified subordinate certification authority.

Notes

  • The information file should contain the certificate extensions needed to specify the qualified subordination constraints for the qualified subordinate certification authority you are installing.
  • When you set up a qualified subordinate CA, you can add a CA policy statement to the CA certificate that is created during setup or a CA certificate renewal, in the form of a text file (CAPolicy.inf) or a pointer to a Web site. The CA policy can contain all the qualified subordination extensions and provide legal and other pertinent information about the CA and its issuing policies, limitations of liability, and so on. An end user will see this CA policy statement when they view the CA certificate and click Issuer Statement.

    For more information about CAPolicy.inf, see "Certificate Services" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

  • When qualified subordinate CA certificates and cross-certificates are revoked, they should also be deleted from the Active Directory directory service. This deletion is not required for security reasons, but is considered a best practice, as it also removes the certificates from the Local Machine certificates store of client computers.

Using a command line

  1. Open Command Prompt.
  2. Type the following to construct a qualified subordination request from an existing CA certificate or from an existing request:

    certreq -policy [Options] [RequestFileIn [PolicyFileIn [RequestFileOut [PKCS10FileOut]]]]

  3. Type the following to sign the qualified subordination request:

    certreq -sign -cert CertId [RequestFileIn [RequestFileOut]]

  4. Type the following to submit the request to the certification authority:

    certreq [-submit] -config CAComputerName\CAName[RequestFileIn [CertFileOut [CertChainFileOut [FullResponseFileOut]]]]

  5. Install the enterprise qualified subordinate certification authority.

    6. For more information, see Related Topics.

Value | Description
certreq | Requests certificates from a certification authority (CA) from the command prompt.
-policy | Required. Sets the policy for a request.
-sign | Required. Signs a cross-certification or qualified subordination request.
Options Specifies one of the following options:
Option | Description
-cert CertId | Specifies the signing certificate by common name, serial number, or by SHA-1 key or certificate hash.
-attrib AttributeString | Specifies the Name and Value string pairs, separated by a colon.
-binary | Formats output files as binary instead of Base64-encoded.
-config CAComputerName\CAName Processes the operation using the CA that is identified in the configuration string specified by CAComputerName\CAName.

Note

  • Using -config - processes the operation using the default CA.
  • If no -config option is used, the Select Certification Authority dialog box displays a list of all available CAs.
-crl | Includes certificate revocation lists (CRLs) in the Base64-encoded PKCS #7 file, CertChainFileOut, or to the Base64-encoded file, RequestFileOut.
-rpc | Instructs Certificate Services to use the RPC server connection instead of DCOM.
RequestFileIn | Specifies the Base64-encoded or binary input file name. May be a PKCS #10 certificate request, PKCS #7 certificate renewal request, KeyGen tag format certificate request, or a CMC request.
CertFileOut | Specifies to send output to either a binary or a Base64-encoded X.509 file.
CertChainFileOut | Specifies to send output to either a binary or a Base64-encoded PKCS #7 file.
FullResponseFileOut | Specifies to send output to either a binary or a Base64-encoded Full Response file. For -submit, this is the name of the qualified subordinate certificate file (for example, QualifiedSub.cer).
PolicyFileIn | Requires Certificate Services to get input from an .inf file containing a textual representation of extensions that are used to qualify a request.
RequestFileOut | Requires Certificate Services to send output to a Base64-encoded file. RequestFileOut for Step 2 will become RequestFileIn for Step 3.
PKCS10FileOut | Requires Certificate Services to send output to a Base64-encoded PKCS #10 file.

Notes

  • XOX
  • To view the complete syntax for this command, at a command prompt, type one of the following:
    • certreq -?
    • certreq -policy -?
    • certreq -sign -?
    • certreq -submit -?
  • Signing the qualified subordination request may require Enterprise Administrator credentials. This is a best practice for issuing signing certificates for qualified subordination.
  • The certificate used to sign the qualified subordination request is created using the qualified subordination template. Enterprise Admins will have to sign the request or grant user permissions for the individuals that will sign the certificate.
  • In Step 3, if you omit -cert CertId, you are prompted to supply the name of the signing certificate.
  • When you install a qualified subordinate CA using the certreq command-line tool, the information (.inf) file can have any name. This is different from when you are using an information file as an issuer policy statement. In that case, the information file must be named CAPolicy.inf, as described in the Windows interface procedure above.
  • When you sign the CMC request, you may need to have multiple personnel sign this request, depending on the assurance level that is associated with the qualified subordination.
  • In some cases, if you omit values at the command line, you will be prompted to supply the necessary information.
  • Once the qualified subordination request is signed, it is automatically published to Active Directory.
  • If the parent CA of the qualified subordinate CA you are installing is offline, you must obtain the CA certificate for the qualified subordinate CA from the offline parent. If the parent CA is online, specify the CA certificate for the qualified subordinate CA during the Certificate Services Installation Wizard.
  • When qualified subordinate CA certificates and cross-certificates are revoked, they should also be deleted from Active Directory. This deletion is not required for security reasons, but is considered a best practice as it also removes the certificates from the Local Machine certificates store of client computers.

Related Topics


Administer a certification authority

  • Start or stop the certification authority service
  • Set security permissions and delegate control of a certification authority
  • View the certification authority certificate
  • Back up a certification authority
  • Restore a certification authority from a backup copy
  • Set security for access to certification authority Web pages
  • Configure certificate manager restrictions
  • Configure event auditing
  • Renew a root certification authority
  • Renew a subordinate certification authority
  • Publish certificates in a foreign Active Directory forest
  • Send email when a certification event occurs
  • Use the Certification Authority snap-in
  • Manage certificate revocation
  • Manage certificate requests on a stand-alone certification authority
  • Manage certificate templates for an enterprise certification authority
  • Manage key archival and recovery
  • Change policy settings of a certification authority
  • Change the policy or exit modules of a certification authority
  • Manage role-based administration


Start or stop the certification authority service

Microsoft Windows graphic

To start or stop the certification authority service

Using the Windows interface

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, point to All Tasks, and click Start Service to start the service or click Stop Service to stop the service.

Note

  • XOX
  • You can also start or stop Certificate Services if you open Computer Management, double-click Services and Applications, and then click Services. In the details pane, click Certificate Services. On the Action menu, click Stop or Start.

Using a command line

  1. Open Command Prompt.
  2. Type:

    net start certsvc to start the service or type net stop certsvc to stop the service.

Value | Description
start | Start the specified service.
stop | Stop the specified service
certsvc | Specifies the Certification Authority service as the service to act on.

Notes

  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    net /?

Related Topics


Set security permissions and delegate control of a certification authority

Microsoft Windows graphic

To set security permissions and delegate control of a certification authority

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. Click the Security tab and specify the security permissions.

    For general information about setting access control security permissions, see Related Topics.

Note

  • XOX

Related Topics


View the certification authority certificate

Microsoft Windows graphic

To view the certification authority certificate

  1. Log on to the system as any CA role holder.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the General tab, click View Certificate.

Note

  • XOX

Related Topics


Back up a certification authority

Microsoft Windows graphic

To back up a certification authority

Using the Windows interface

  1. Log on to the system as a Backup Operator or a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, point to All Tasks, and click Back Up CA.
  5. Follow the instructions in the Certification Authority Backup Wizard.

Notes

  • XOX

  • This procedure is useful if you want to back up a CA without backing up the entire server on which the CA is installed.

    In general, you should use Backup to back up and restore both the CA and the server. For more information about backing up a computer running a Windows Server 2003 operating system, see Related Topics.

  • By default, members of the local Administrators group for the certification authority can also back up the certification authority.

Using a command line

  1. Open Command Prompt.
  2. Type:

    certutil -backup BackupDirectory

Value | Description
backup | Specifies a full backup of the CA's data.
BackupDirectory | Specifies the path to use to store the backup data.

Notes

  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    certutil -backup -?

Related Topics


Restore a certification authority from a backup copy

Microsoft Windows graphic

To restore a certification authority from a backup copy

Using the Windows interface

  1. Log on to the system as a Backup Operator or a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, point to All Tasks, and click Restore CA.
  5. Follow the instructions in the Certification Authority Restore Wizard.

Notes

  • XOX

  • This procedure is useful if you want to restore a CA without restoring the entire server on which the CA is installed. To back up the CA for later restoration using this procedure, see Related Topics.

    In general, you should use Backup to back up and restore both the CA and the server. For more information about backing up a computer running a Windows Server 2003 operating system, see Related Topics.

Using a command line

  1. Open Command Prompt.
  2. Type:

    certutil -restore BackupDirectory

Value | Description
restore | Specifies a full restore of the CA's data.
BackupDirectory | Specifies the path where the backup data is located.

Notes

  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    certutil -restore -?

Related Topics


Set security for access to certification authority Web pages

Microsoft Windows graphic

To set security for access to certification authority Web pages

  1. Log on to the system as an Internet Information Services Administrator.
  2. Click Start, point to Programs, point to Administrative Tools, and then click Internet Information Services.
  3. In the console tree, right-click CertSrv, and click Properties.

    Where?

    • Internet Information Services
    • Computer Name
    • Web Sites
    • Default Web Site
    • CertSrv
  4. On the Directory Security tab, under Anonymous access and authentication control, click Edit.
  5. Clear all check boxes except Integrated Windows authentication.

Important

  • An enterprise certification authority (CA) requires that the certificate requester be authenticated by the page so that it can determine the correct information to put in the certificate. If you don't have authentication set for the Web pages in an enterprise CA, then the pages will fail to generate a certificate or, if a certificate is generated, it will be useless. For this reason, integrated Windows authentication is set by default on enterprise CAs. This procedure is provided so that you can confirm the default setting or fix an erroneous change to the IIS Directory Security settings for an enterprise certification authority.

Notes

  • You do not need to perform this procedure on a stand-alone certification authority.
  • If you cannot locate CertSrv in the console tree, confirm that Certificate Services is installed.
  • If Certificate Services is installed and the CertSrv virtual directory doesn't exist, run certutil -vroot from the command prompt to create it.

Related Topics


Configure certificate manager restrictions

Microsoft Windows Graphic

To configure certificate manager restrictions

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Certificate Manager Restrictions tab, click Restrict certificate managers.
  6. In Available certificate managers, select the certificate manager subject or group you want.
  7. Click Add to add groups, users or computers to manage for the selected certificate manager.

Notes

  • XOX
  • If a CA is running on a member server and the Restrict certificate managers property is enabled, then the member server needs to be added to the Pre-Windows 2000 Compatible Access built-in group of every domain from which it will receive certificate requests. Once added to these groups, the administrator of the CA is allowed to issue a certificate for subjects in those domains. For more information on the Pre-Windows 2000 Compatible Access built-in group, see "Active Directory Data Storage" at the Microsoft Windows Resource Kits Web site (http://www.microsoft.com/).

Related Topics


Configure event auditing

Microsoft Windows graphic

To configure event auditing

  1. Log on to the system as a Certification Authority Administrator or a CA Auditor.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Auditing tab, click the events you want to audit.

Note

  • XOX
  • CA auditing is only available on servers running XOX and XOX, including the 64-bit version of XOX and 64-bit version of XOX.
  • To audit events, the computer must also be configured for auditing of object access. Also, the auditor must perform this operation if the certification authority has been configured to enforce role-based administration. For more information, see Related Topics.

Related Topics


Renew a root certification authority

Microsoft Windows graphic

To renew a root certification authority

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, point to All Tasks, and click Renew CA Certificate.
  5. Do one of the following:
    • If you want to generate a new public and private key pair for the certification authority's certificate, click Yes.
    • If you want to reuse the current public and private key pair for the certification authority's certificate, click No.

Note

  • XOX

Related Topics


Renew a subordinate certification authority

Microsoft Windows graphic

To renew a subordinate certification authority

Using the Windows interface

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, point to All Tasks, and click Renew CA Certificate.
  5. Do one of the following:
    • If you want to generate a new public and private key pair for the certification authority's certificate, click Yes.
    • If you want to reuse the current public and private key pair for the certification authority's certificate, click No.
  6. Get the CA certificate from the parent CA. For more information, see Notes.

Notes

  • XOX
  • To obtain the certificate for a subordinate CA, you must submit a certificate request to a parent CA. The procedure for doing so differs depending on whether the parent CA is available online.

    • If a parent CA is available online

      1. Click Send the request directly to a CA already on the network.
      2. In Computer Name, type the name of the computer on which the parent CA is installed.
      3. In Parent CA, click the name of the parent CA.

    • If a parent CA is not available online

      1. Click Save the request to a file.
      2. In Request file, type the path and file name of the file that will store the request.
      3. Obtain this subordinate CA's certificate from the parent CA.

        The procedure for doing this will be unique to the parent CA. At a minimum, the parent CA should provide a file containing the subordinate CA's newly issued certificate and, preferably, its full certification path. For the procedure to submit a certificate request using a file to a Microsoft CA, see Related Topics.

        If you get a subordinate CA certificate that does not include the full certification path, the new subordinate CA you are installing must be able to build a valid CA chain when it starts. Thus you must install the parent CA's certificate in the Intermediate Certification Authorities certificate store of the computer (if the parent CA is not a root CA), as well as the certificates of any other intermediate CA in the chain, and you must install the certificate of the root CA in the chain into the Trusted Root Certification Authorities store. These certificates should be installed in the certificate store before you install the CA certificate on the subordinate CA you have just set up.

      4. Open Certification Authority.
      5. In the console tree, click the name of the CA.

        Where?

        • Certification Authority (Computer)
        • CA name
      6. On the Action menu, point to All Tasks, and then click Install CA Certificate.
      7. Locate the certificate file received from the parent certification authority, click this file, and then click Open.

Using a command line

  1. Open Command Prompt.
  2. Type:

    certutil -renewcert

Value | Description
renewcert | Instructs the CA to renew its certificate.

Notes

  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    certutil -renewcert -?

Related Topics


Publish certificates in a foreign Active Directory forest

Microsoft Windows Graphic

To publish certificates in a foreign Active Directory forest

  1. Log on to the system as an administrator.
  2. Open Command Prompt.
  3. Type:

    4. certutil -setreg CA\AlternatePublishDomains +"DomainName"

Value | Description
certutil | Specifies the name of the command-line program.
-setreg | Modifies the registry.
CA\AlternatePublishDomains | Indicates the registry value that contains a list of Active Directory domains that receive certificate publication.
+ | Indicates that if there are current entries stored in this registry value, append this entry to those.
DomainName | Specifies the fully-qualified DNS domain name of the foreign Active Directory domain to publish certificates in.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

Notes

  • XOX
  • XOX
  • A forest trust relationship must exist between the CA's forest and the forest that certificates will be published in before publication in the foreign domain. For more information, see Related Topics.
  • The default permissions in a trust across forests do not allow certificate publication from a foreign forest. To grant the appropriate permissions, use the Delegation of Control Wizard on the foreign Active Directory's root domain to make the following settings:
    Setting | Value
    Selected users and groups | Certificate Publishers group in the foreign Active Directory domain
    Tasks to delegate | Create a custom task to delegate
    Delegate control of: Under Only the following objects in the folder, select Contact objects
    Show these permissions | Click Property-specific, then select Read userCertificate and Write userCertificate
    For more information on running the Delegation of Control Wizard, see Related Topics.
  • The default membership of the foreign Active Directory's Cert Publishers group does not include the source CA. The source CA's Active Directory computer account must be added to the foreign Cert Publishers group before publishing across forests will work. Because computer accounts cannot be found across trusts across forests by browsing, ensure you know the name of the CA to add.
  • Publication of certificates in a foreign Active Directory requires the e-mail property in the source forest's User object match the e-mail property in the destination forest's Contact object. The e-mail property must be populated on User objects for this to happen. For more information on changing properties of a User object, see Related Topics.
  • To view the complete syntax for this command, at a command prompt, type:

    certutil -setreg -?

Related Topics


Send e-mail when a certification event occurs

Microsoft Windows Graphic

To send e-mail when a certification event occurs

  1. Open Command Prompt.
  2. Type:

    certutil -setreg exit\smtp\smtpserver ServerName

    and then type:

    certutil -setreg exit\smtp\eventfilter +Event

Value | Description
certutil | Specifies the name of the command-line program.
-setreg | Modifies the registry.
exit\smtp\smtpserver | Indicates the registry value that contains the name of the Simple Mail Transfer Protocol (SMTP) server.
exit\smtp\eventfilter | Indicates the registry value that contains the list of events that the certification authority (CA) should monitor. When any of these events occur, the CA will send e-mail.
+ | Indicates that, if there are current entries stored in this registry value, this entry should be appended to them.
Event | Specifies the event to add to the list of events for the CA to monitor. An event can be any value in the following table:

Event value | Description
ExitEvent_CertIssued | Specifies the action of issuing a certificate.
ExitEvent_CertPending | Specifies the action of a certificate request being received by the CA and set to Pending.
ExitEvent_CertDenied | Specifies the action of a certificate request being received by the CA and that request being denied.
ExitEvent_CertRevoked | Specifies the action of a revocation of an existing certificate.
ExitEvent_CRLIssued | Specifies the action of a certificate revocation list being issued.
ExitEvent_Startup | Specifies the action of the certification authority starting.
ExitEvent_Shutdown | Specifies the action of the certification authority shutting down.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

Notes

  • XOX
  • XOX
  • When the ExitEvent_CRLIssued, ExitEvent_Startup and ExitEvent_Shutdown events occur, the CA does not know where to send the e-mail, as there is no user associated with this event. Therefore, an e-mail address must be configured when using these events. To configure the e-mail address to send e-mail to when these events occur, type the following certutil.exe commands at a command prompt:

    certutil -setreg exit\smtp\CRLIssued\To E-mailString

    certutil -setreg exit\smtp\Startup\To E-mailString

    certutil -setreg exit\smtp\Shutdown\To E-mailString

    E-mailString specifies an e-mail address or a string of e-mail addresses that are separated by semicolons.
  • If the SMTP server is not set to accept anonymous connections, the CA must be configured to provide a user name and password when it connects. To configure the CA to authenticate with the SMTP server, type the following certutil.exe commands at a command prompt:

    certutil -setreg exit\smtp\SMTPAuthenticate 1

    certutil -setsmtpinfo UserName

    UserName specifies the user name of a valid account on the SMTP server. Certutil will prompt you to provide the password for this user name.
  • To view the complete syntax for this command, at a command prompt, type:

    certutil -setreg -?

    • For more information about configuring a certification authority for e-mail, see "Designing a Public Key Infrastructure" at the Microsoft Windows Resource Kits Web site. (http://www.microsoft.com/)

Related Topics


Use the Certification Authority snap-in

  • Administer the certification authority on this computer
  • Administer the certification authority on another computer
  • Set display filters for the Certification Authority snap-in
  • Customize the display of columns in Certification Authority


Administer the certification authority on this computer

Microsoft Windows graphic

To administer the certification authority on this computer

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.

Note

  • XOX

Related Topics


Administer the certification authority on another computer

Microsoft Windows graphic

To administer the certification authority on another computer

  1. Log on to the system as a Certification Authority Administrator of the remote CA.
  2. Open Certification Authority.
  3. On the Action menu, click Retarget Certification Authority.
  4. Click Another computer and type the name of the computer.

Notes

  • XOX
  • As an alternate way to manage a CA on another computer, perform the following steps:
    1. Log on to the system as an Administrator.
    2. Click Start, click Run, type mmc, and then click OK.
    3. On the File menu, click Add/Remove Snap-in. Click Add.
    4. In Snap-in, double-click Certification Authority.
    5. Click Another computer and type the name of the computer.

Related Topics


Set display filters for the Certification Authority snap-in

Microsoft Windows graphic

To set display filters for the Certification Authority snap-in

  1. Log on to the system as any CA role holder.
  2. Open Certification Authority.
  3. In the console tree, double-click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. Click any of the displayed folders except Certificate templates.
  5. On the View menu, click Filter.
  6. For each of the selection criteria:
    • Click Add.
    • In Field, click the field on which to filter.
    • In Operation, click the operation to qualify the filter value for this field.
    • In Value, type the qualification value.

Notes

  • XOX
  • Display filters are essentially a way to make simple queries against a CA's database. By using filters, you can restrict the items displayed in the details pane of the Certification Authority snap-in to items that meet a set of criteria you establish. For example, you can create a filter that will display in the Issued Certificates folder only those certificates that were effective after a specific date.
  • To remove a filter, click it in the Filter dialog box, and then click Remove.
  • To remove all existing filters, in the Filter dialog box, click Reset.

Related Topics


Customize the display of columns in Certification Authority

Microsoft Windows graphic

To customize the display of columns in Certification Authority

  1. Log on to the system as any CA role holder.
  2. Open Certification Authority.
  3. In the console tree, double-click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. Click any of the displayed folders, such as Revoked Certificates or Issued Certificates.
  5. On the View menu, click Add/Remove Columns.
  6. Do any of the following until you have made all of the changes that you want.
    To | Do this
    Add a new column to the details pane | In Available Columns, click the column you want to add to the details pane. Click Add.
    Remove a column from the details pane | In Displayed Columns, click the column you want to remove from the details pane. Click Remove.
    Change the order of columns in the details pane | In Displayed Columns, click the column you want to move up or down in the order of the details pane. Click Move Up or Move Down as appropriate.
    Restore the default columns | Click Restore Defaults.

Notes

  • XOX
  • To sort the results, click the column heading in the details pane. You can only sort results based on columns (indicating the fields) that are indexed in the database of the certification authority. There will be a small arrow on the column heading you are sorting by.

Related Topics


Manage certificate revocation

  • Specify certificate revocation list distribution points in issued certificates
  • Configure CRL and delta CRL overlap period
  • Specify online certificate status protocol responder in issued certificates
  • Configure an offline root certification authority to support certificate revocation with Active Directory
  • Revoke an issued certificate
  • Schedule the publication of the certificate revocation list
  • Schedule the publication of the delta certificate revocation list
  • Manually publish the certificate revocation list
  • View the certificate revocation list


Specify certificate revocation list distribution points in issued certificates

Microsoft Windows graphic

To specify certificate revocation list distribution points in issued certificates

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the certification authority.

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Extensions tab, confirm that Select extension is set to CRL Distribution Point (CDP).
  6. Do one or more of the following. (The list of CRL distribution points is in the Specify locations from which users can obtain a certificate revocation list (CRL) box.)
    To | Do this
    Add a new certificate revocation list (CRL) distribution point. | Click Add, type the name of the new CRL distribution point, and click OK.
    Remove a CRL distribution point from the list. | Click the CRL distribution point, and then click Remove and click OK.
    Indicate that you want to use a URL as a CRL distribution point. | Click the CRL distribution point, select the Include in the CDP extension of issued certificates check box, and then click OK.
    Indicate that you do not want to use a URL as a CRL distribution point. | Click the CRL distribution point, clear the Include in the CDP extension of issued certificates check box, and then click OK.
    Indicate that you want to use a URL as a delta CRL distribution point. | Click the CRL distribution point, select the Publish Delta CRLs to this location check box, and then click OK.
    Indicate that you do not want to use a URL as a delta CRL distribution point. | Click the CRL distribution point, clear the Publish Delta CRLs to this location check box, and then click OK.
    Indicate that you want to publish this location in CRLs to point clients to a delta CRL. | Click the CRL distribution point, select the Include in CRLs. Clients use this to find Delta CRL locations. check box, and then click OK.
    Indicate that you do not want to publish this location in CRLs to point clients to a Delta CRL. | Click the CRL distribution point, clear the Include in CRLs. Clients use this to find Delta CRL locations. check box, and then click OK.
  7. Click Yes to stop and restart the Certificate Services service.

Notes

  • XOX
  • Certificate revocation list URLs can be either HTTP, FTP, LDAP, or FILE addresses. You can use the following variables when specifying the address of the CRL.
    Variable | Value
    CAName | The name of the certification authority
    CAObjectClass | The object class identifier for a certification authority, used when publishing to an LDAP URL
    CATruncatedName | The "sanitized" name of the certification authority, truncated to 32 characters with a hash on the end
    CDPObjectClass | The object class identifier for CRL distribution points, used when publishing to an LDAP URL
    CertificateName | The renewal extension of the certification authority
    ConfigurationContainer | The location of the Configuration container in Active Directory
    CRLNameSuffix | Inserts a name suffix at the end of the file name when publishing a CRL to a file or URL location
    DeltaCRLAllowed | When a delta CRL is published, this replaces the CRLNameSuffix with a separate suffix to distinguish the delta CRL
    ServerDNSName | The DNS name of the certification authority server
    ServerShortName | The NetBIOS name of the certification authority server
  • To stop and restart the Certificate Services service, see Related Topics.

Related Topics


Configure CRL and delta CRL overlap period

Microsoft Windows Graphic

To configure CRL and delta CRL overlap period

  1. Open Command Prompt.
  2. Type:

    3. certutil -setreg ca\CRLOverlapUnits Value

    certutil -setreg ca\CRLOverlapPeriod Units

    certutil -setreg ca\CRLDeltaOverlapUnits Value

    certutil -setreg ca\DeltaOverlapPeriod Units

  3. Open Certification Authority.
  4. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  5. On the Action menu, point to All Tasks, and click Stop Service to stop the service.
  6. On the Action menu, point to All Tasks, and click Start Service to start the service.
Value | Description
certutil | Specifies the name of the command-line program.
-setreg | Modifies the registry.
ca\CRLOverlapUnits | Indicates the registry value that stores the value for the CRL overlap setting.
ca\CRLDeltaOverlapUnits | Indicates the registry value that stores the value for the delta CRL overlap setting.
Value | Provides the numerical value to set this option to.
ca\CRLOverlapPeriod | Indicates the registry value that stores the value for the CRL overlap unit type setting.
ca\DeltaOverlapPeriod | Indicates the registry value that stores the value for the delta CRL overlap unit type setting.
Units | Provides the type of units for the overlap period. Valid values are Minutes and Hours.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

Notes

  • XOX
  • XOX
  • XOX
  • The maximum value for either the CRL or delta CRL overlap period is 12 hours.
  • The overlap period for CRLs is the amount of time at the end of a published CRLs lifetime that a client can use to obtain a new CRL before the old CRL is considered unusable. The default setting for this value is 10% of the CRL lifetime. Because some environments may require longer periods to replicate a CRL, this setting can be configured manually.
  • When both a base CRL and delta CRL have been recently published, a revoked certificate may appear in both. This is because the newer delta CRL may still point at the older base CRL while the new base CRL is being replicated. Having the certificate appear in both CRLs ensures the revocation information is available.
  • If your environment is not configured to issue delta CRLs, the settings for CRLDeltaOverlapUnits and DeltaOverlapPeriod will have no effect.
  • To view the complete syntax for this command, at a command prompt, type:

    certutil -setreg -?

Related Topics


Specify online certificate status protocol responder in issued certificates

Microsoft Windows graphic

To specify online certificate status protocol (OCSP) responder in issued certificates

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the certification authority.

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Extensions tab, under Select extension, click Authority Information Access (AIA).
  6. Do one or more of the following. (The list of OCSP responders is in the Specify locations from which users can obtain a certificate revocation list (CRL) box.)
    To | Do this
    Add a new OCSP responder. | Click Add, type in the location of the new CRL distribution point, and then click OK.
    Remove a OCSP responder from the list. | Click the OCSP responder, click Remove, and then click OK.
    Indicate that you do not want to use a URL as an OCSP responder. | Click the OCSP responder, clear the Include in the online certificate status protocol (OCSP) extension check box, and then click OK.
    Indicate that you want to use a URL as an OCSP responder. | Click the OCSP responder, select the Include in the online certificate status protocol (OCSP) extension check box, and then click OK.
  7. On the Action menu, point to All Tasks, click Stop Service, and on the Action menu, point to All Tasks, and then click Start Service.

Notes

  • XOX
  • OCSP responder list URLs can be HTTP, FTP, LDAP, or FILE addresses.

Related Topics


Configure an offline root certification authority to support certificate revocation with Active Directory

Microsoft Windows Graphic

To configure an offline root certification authority to support certificate revocation with Active Directory

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Command Prompt.
  3. Type the following, and then press ENTER.

    certutil -setreg ca\DSConfigDN "CN=Configuration,DNpath"

  4. Type the following, and then press ENTER.

    certutil -setreg ca\DSDomainDN "DNpath"

  5. Open Certification Authority.
  6. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  7. On the Action menu, point to All Tasks, and click Stop Service to stop the service.
  8. On the Action menu, point to All Tasks, and click Start Service to start the service.
Value | Description
certutil | Specifies the name of the command-line program.
-setreg | Modifies the registry.
ca\DSConfigDN | Indicates the registry value for the distinguished name value of the path to the Configuration container in the Active Directory directory service.
ca\DSDomainDN | Indicates the registry value for for the distinguished name value of the Active Directory domain.
DNpath | Specifies the distinguished name value in Active Directory. Fore more information, see Related Topics.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

Notes

  • XOX
  • XOX
  • XOX
  • To ensure clients have the ability to locate the certificate revocation list (CRL), the certification authority (CA) must be configured with the appropriate LDAP path to retrieve this CRL from Active Directory. This is done by selecting the Include in the CDP extension of issued certificates check box when configuring the CDP. For more information, see Related Topics.
  • This procedure should be used as part of a larger plan to deploy an offline root CA. For more information about deploying an offline root CA, see Related Topics.
  • To view the complete syntax for this command, at a command prompt, type:

    certutil -setreg -?

Related Topics


Revoke an issued certificate

Microsoft Windows graphic

To revoke an issued certificate

Using the Windows interface

  1. Log on to the system as a Certification Authority Administrator or Certificate Manager.
  2. Open Certification Authority.
  3. In the console tree, click Issued Certificates

    Where?

    • Certification Authority (Computer)
    • CA name
    • Issued Certificates
  4. In the details pane, click the certificate you want to revoke.
  5. On the Action menu, point to All Tasks, and click Revoke Certificate.
  6. Select the reason for revoking the certificate and click Yes.

Notes

  • XOX
  • The certificate is marked as revoked and is moved to the Revoked Certificates folder. The revoked certificate will appear on the certificate revocation list (CRL) the next time it is published.
  • Certificates revoked with the reason code "Certificate Hold" can be unrevoked, left on "Certificate Hold" until they expire, or have their revocation reason code changed. "Certificate Hold" is the only revocation reason that will allow you to unrevoke the certificate. It is useful if the status of the certificate is questionable and is meant to provide some flexibility to the CA administrator.

    • To unrevoke a certificate revoked with the reason code "Certificate Hold," at a command prompt on the CA, type

      certutil -revoke CertificateSerialNumber unrevoke

      To identify the certificate serial number, in the Revoked Certificates folder, in the details pane, double-click the revoked certificate, and then click the Details tab.

    • To change the reason code for a certificate previously revoked with the reason code "Certificate Hold," type the appropriate command at a command prompt on the CA.

      New reason code | Command
      Unspecified | certutil -revoke CertificateSerialNumber 0
      Key Compromise | certutil -revoke CertificateSerialNumber 1
      CA Compromise | certutil -revoke CertificateSerialNumber 2
      Affiliation Changed | certutil -revoke CertificateSerialNumber 3
      Superseded | certutil -revoke CertificateSerialNumber 4
      Cessation of Operation | certutil -revoke CertificateSerialNumber 5
  • You can also unrevoke a certificate in the Certification Authority by right-clicking the certificate you want, clicking All Tasks, then clicking Unrevoke Certificate. This certificate must be revoked for the reason of "Certificate Hold".

Using a command line

  1. Open Command Prompt.
  2. Type:

    certutil -revoke SerialNumber ReasonCode

Value | Description
revoke | Specifies the revocation of an existing certificate.
SerialNumber | Specifies the serial number of the certificate for revocation.
ReasonCode | Specifies the reason code for this certificate revocation. For values, see Notes.

Notes

  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    certutil -revoke -?

  • The valid reason codes for certificate revocation are:
    Reason for
    revoking a certificate     		Reason code
    Unspecified | 0
    Key Compromise | 1
    CA Compromise | 2
    Affiliation Changed | 3
    Superseded | 4
    Cessation of Operation | 5
    Certificate Hold | 6
  • Certificates that are revoked with the reason code "Certificate Hold" can be unrevoked, left on "Certificate Hold" until they expire, or have their revocation reason code changed. "Certificate Hold" is the only revocation reason that will allow you to unrevoke the certificate. It is useful if the status of the certificate is questionable and is meant to provide some flexibility to the CA administrator.

  • To unrevoke a certificate that is revoked with the reason code "Certificate Hold," at a command prompt on the CA, type

    certutil -revoke CertificateSerialNumber unrevoke

Related Topics


Schedule the publication of the certificate revocation list

Microsoft Windows graphic

To schedule the publication of the certificate revocation list

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click Revoked Certificates.

    Where?

    • Certification Authority (Computer)
    • CA name
    • Revoked Certificates
  4. On the Action menu, click Properties.
  5. In CRL publication interval, type the increment and click the unit of time to use for the automatic publishing of the certificate revocation list (CRL).

Notes

  • XOX
  • The certificate revocation list (CRL) is published by default in:

    systemroot\system32\CertSrv\CertEnroll\

    If the computer is a domain member and has permission to write to the Active Directory directory service, then the CRL is also published to Active Directory.

  • The publishing period for a CRL is not the same as the validity period for a CRL. By default, the validity period of a CRL exceeds the publishing period of a CRL by 10% (up to a 12-hour maximum) to allow for directory replication. For more information about revoking certificates and publishing CRLs, see Related Topics.

Related Topics


Schedule the publication of the delta certificate revocation list

Microsoft Windows graphic

To schedule the publication of the delta certificate revocation list

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click Revoked Certificates.

    Where?

    • Certification Authority (Computer)
    • CA name
    • Revoked Certificates
  4. On the Action menu, click Properties.
  5. Select the Publish Delta CRLs check box.
  6. In Publication interval, type the increment and click the unit of time to use for the automatic publishing of the delta certificate revocation list (CRL).

Notes

  • XOX
  • The delta certificate revocation list (CRL) is published by default in:

    Systemroot\system32\CertSrv\CertEnroll\

    If the computer is a domain member and has permission to write to Active Directory, then the delta CRL is also published to Active Directory.

  • The publishing period for a CRL is not the same as the validity period for a CRL. By default, the validity period of a CRL exceeds the publishing period of a CRL by 10% (up to a 12-hour maximum) to allow for directory replication. For more information about revoking certificates and publishing CRLs, see Related Topics.

Related Topics


Manually publish the certificate revocation list

Microsoft Windows graphic

To manually publish the certificate revocation list

Using the Windows interface

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click Revoked Certificates.

    Where?

    • Certification Authority (Computer)
    • CA name
    • Revoked Certificates
  4. On the Action menu, point to All Tasks, and click Publish.
  5. Select New CRL to overwrite the previously-published certificate revocation list (CRL), or select Delta CRL only to publish a current delta CRL.

Notes

  • XOX
  • Clients that have a cached copy of the previously-published CRL or delta CRL will continue using it until its validity period has expired, even though a new CRL has been published. Manually publishing a CRL does not affect cached copies of CRLs that are still valid; it only makes a new CRL available for systems that do not have a valid CRL.

    See Related Topics for the procedure clients can use to get the most recent CRL published by the certification authority (CA) even if they still have a valid CRL cached.

  • By default, on the server on which the CA is installed, the CRL and delta CRL are published in:

    Systemroot\system32\CertSrv\CertEnroll\

    If the Active Directory directory service is available, they are also published to Active Directory.

Using a command line

  1. Open Command Prompt.
  2. Type:

    certutil -crl

Value | Description
crl | Specifies that a full certificate revocation list will be published.

Notes

  • XOX
  • To view the complete syntax for this command, at a command prompt, type:

    certutil -crl -?

Related Topics


View the certificate revocation list

Microsoft Windows graphic

To view the certificate revocation list

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click Revoked Certificates.

    Where?

    • Certification Authority (Computer)
    • CA name
    • Revoked Certificates
  4. On the Action menu, click Properties.
  5. Click the View CRLs tab.
  6. Click View CRL to view the certificate revocation list or View Delta CRL to view the delta certificate revocation list.
  7. Click the Revocation List tab.

Notes

  • XOX

Related Topics


Manage certificate requests on a stand-alone certification authority

  • Review pending certificate requests
  • Set the default action upon receipt of a certificate request


Review pending certificate requests

Microsoft Windows graphic

To review pending certificate requests

  1. Log on to the system as a Certification Authority Administrator or Certificate Manager.
  2. Open Certification Authority.
  3. In the console tree, click Pending Requests.

    Where?

    • Certification Authority (Computer)
    • CA name
    • Pending Requests
  4. In the details pane, examine the certificate request by noting the values for requester name, requester e-mail address, and any other fields that you consider critical information for issuing the certificate.
  5. To | Do this
    Reject the certificate request | Click the certificate request and on the Action menu, point to All Tasks, click Deny, and then click Yes.
    Issue the certificate | Click the certificate request and on the Action menu, point to All Tasks, and then click Issue.

Notes

  • XOX
  • Failed certificate requests can also be issued using the same procedure in the Failed Requests container. However, not all of the security requirements for the certificate can be verified when issuing a failed request. Caution should be used.

Related Topics


Set the default action upon receipt of a certificate request

Microsoft Windows graphic

To set the default action upon receipt of a certificate request

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Policy Module tab, click Properties.
  6. Click the option you want:
    To | Do this
    Have the certification authority administrator review every certificate request before issuing a certificate. | Click Set the certificate request status to pending.
    Have the certification authority issue certificates based on the configuration of the certificate template | Click Follow the settings in the certificate template, if applicable. Otherwise, automatically issue the certificate..
  7. Stop and restart the Certificate Services service.

Caution

  • In most cases, for security reasons, it is strongly recommended that all incoming certificate requests to a stand-alone CA be marked as "pending." Unlike enterprise certification authorities, stand-alone CAs do not use the Active Directory directory service, even if it is available, to verify that an individual or computer is authorized to be issued a certificate from the CA automatically. For stand-alone CA's, the CA administrator is responsible for verifying the identity of the certificate requestor.

Notes

  • XOX
  • If you change the setting from Set the certificate request status to pending to Always issue the certificate, this will apply only to certificate requests submitted to the CA after the default action has been changed. If there are pending requests held by the CA, these requests will stay pending until the CA administrator issues the certificates or denies the requests.
  • To review pending certificate requests, see Related Topics.
  • To stop and restart the Certificate Services service, see Related Topics.

Related Topics


Manage certificate templates for an enterprise certification authority

  • Install new templates and upgrade existing templates
  • Create a new certificate template
  • Delete a certificate template
  • Add a certificate template to a certification authority
  • Allow subjects to request a certificate that is based on the template
  • Re-enroll all certificate holders
  • Remove a certificate template from a certification authority
  • Modify a certificate template


Manage key archival and recovery

  • Configure a certificate template for key archival and recovery
  • Identify a key recovery agent
  • Enable key archival
  • Certutil tasks for key archival and recovery


Identify a key recovery agent

Microsoft Windows Graphic

To identify a key recovery agent

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Recovery Agents tab, click Archive the key.
  6. In the Number of recovery agents to use box, type the number of key recovery agents required to recover an archived key.
  7. Click Add to add key recovery agent certificates.

Notes

  • XOX
  • To add key recovery agents, the Number of recovery agents to use must be 1 or more.
  • If the Number of recovery agents to use value exceeds the number of recovery agent certificates with the status of "Valid," enrollment requests that require key archival will fail.
  • This procedure configures a certification authority to archive private keys when issuing certificates based on templates that have key archival configured. For more information about configuring certificate templates for key archival, see Related Topics.
  • When the recovery agent certificates are added to the CA, a status is displayed for each certificate. Status can be one of the following values and causes:
    Status | Cause
    Expired | The certificate's expiration date has passed so the certificate cannot be used.
    Invalid | The certificate may be malformed or causes and error when loading.
    Not found | The certificate was configured but cannot be located by the CA.
    Not loaded | The certificate was configured but has not yet been loaded by the CA.
    Revoked | The certificate has been revoked and cannot be used.
    Untrusted | The root CA for this certificate is not trusted by the CA.
    Valid | The certificate has been loaded by the CA and is operating normally.

Related Topics


Enable key archival

Microsoft Windows graphic

To enable key archival

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. Click the Recovery Agents tab and click Archive the key.
  6. In the Number of recovery agents to use box, specify the number of recovery agents required to recover an archived key, and then add the recovery agents that you want to the Key recovery agent certificates list.

Note

  • XOX

Related Topics


Change policy settings of a certification authority

  • Specify CA certificate access points in issued certificates
  • Publish certificates to the file system


Specify CA certificate access points in issued certificates

Microsoft Windows graphic

To specify CA certificate access points in issued certificates

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Extensions tab, click Select extension, and then click Authority Information Access (AIA).
  6. Specify the locations from which users can obtain the certificate for this CA.
    To | Do this
    Add a URL that will be published as part of any certificate issued by a CA. | Click Add, then type a URL where users can obtain the CA's certificate.
    Remove an authority information URL from the list on issued certificates. | Click the URL and then click Remove.
    Indicate that that you do not want to use a URL as an authority information access point in certificates without removing it from the list. | Clear the Include in the AIA extension of issued certificates check box.
    Indicate that a URL can now be used as an authority information access point. | Select the Include in the AIA extension of issued certificates check box.
    Indicate that a URL can now be used for online certificate status protocol (OCSP). | Select the Include in the online certificate status protocol (OCSP) extension check box.
    Indicate that that you do not want to use a URL for online certificate status protocol (OCSP) in certificates without removing it from the list. | Clear the Include in the online certificate status protocol (OCSP) extension check box.
  7. Stop and restart the Certificate Services service.

Notes

  • XOX

  • Authority information access URLs can be either HTTP, FTP, LDAP, or FILE addresses. You can use the following variables when specifying the address of the authority information access point:

    Variable | Value
    CAName | The name of the certification authority.
    CAObjectClass | The object class identifier for a certification authority, used when publishing to an LDAP URL
    CATruncatedName | The "sanitized" name of the certification authority, truncated to 32 characters with a hash on the end
    CDPObjectClass | The object class identifier for CRL distribution points, used when publishing to an LDAP URL
    CertificateName | The renewal extension of the certification authority
    ConfigurationContainer | The location of the Configuration container in Active Directory
    CRLNameSuffix | Inserts a name suffix at the end of the file name when publishing a CRL to a file or URL location
    DeltaCRLAllowed | When a delta CRL is published, this replaces the CRLNameSuffix with a separate suffix to distinguish the delta CRL
    ServerDNSName | The DNS name of the certification authority server
    ServerShortName | The NetBIOS name of the certification authority server
  • To stop and restart the Certificate Services service, see Related Topics.

Related Topics


Publish certificates to the file system

Microsoft Windows graphic

To publish certificates to the file system

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Exit Module tab, click Properties.
  6. On the Publication Settings tab, select the Allow certificates to be published to the file system check box, and then click OK.
  7. Stop and restart the Certification Authority service.

Notes

  • XOX
  • To stop and restart Certificate Services, see Related Topics.
  • To request a certificate and have it published to the file system, certificate requestors must include a certfile:true attribute in their request. After the certificate is issued, it is copied to FileName.cer, where FileName is the request ID of the certificate request.
    • The file is written in the CertEnroll share on the CA.
    • You cannot overwrite files using this method.

Related Topics


Change the policy or exit modules of a certification authority

  • Select a different policy module
  • Select a different exit module


Select a different policy module

Microsoft Windows graphic

To select a different policy module

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Policy Module tab, click Select
  6. Click the new policy module, and then click OK.
  7. If the policy module has its own configuration interface, you can configure it by clicking Properties.
  8. Stop and restart the Certificate Services service.

Notes

  • XOX
  • To register a new policy module so that it is available in the list of policy modules, refer to the Microsoft Platform Software Development Kit.
  • Only one policy module can be active.
  • To stop and restart the Certificate Services service, at the command prompt, type:

    • net stop certsvc

    net start certsvc

Related Topics


Select a different exit module

Microsoft Windows graphic

To select a different exit module

  1. Log on to the system as a Certification Authority Administrator.
  2. Open Certification Authority.
  3. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  4. On the Action menu, click Properties.
  5. On the Exit Module tab, click Add
  6. Click the new exit module and then click OK.
  7. (Optional) If the exit module has its own configuration interface, to configure it, click Properties.
  8. Stop and restart the Certificate Services service.

Notes

  • XOX
  • To register a new exit module so that it is available in the list of exit modules, refer to the Microsoft Platform Software Development Kit.
  • To stop and restart the Certificate Services service, at a command prompt, type:

    • net stop certsvc

    net start certsvc

  • Multiple exit policies can be enabled at the same time.

Related Topics


Manage role-based administration

Microsoft Windows graphic

Managing role-based administration

  • Add a certification authority administrator
  • Add a certificate manager
  • Add a certification authority auditor
  • Add a certification authority backup operator
  • Enable role separation
  • Disable role separation


Add a certification authority administrator

Microsoft Windows Graphic

To add a certification authority administrator

  1. Open Certification Authority
  2. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  3. On the Action menu, click Properties.
  4. Click the Security tab, in Group or user names, confirm that Administrators is selected, and then click Add.
  5. In Permissions for Administrators, type the name of the group or user you want to make a CA Administrator, and then click OK.
  6. In Permissions for Added User or Group, for Manage CA, select the Allow check box.

Notes

  • XOX
  • XOX

Related Topics


Add a certificate manager

Microsoft Windows Graphic

To add a certificate manager

  1. Open Certification Authority
  2. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  3. On the Action menu, click Properties.
  4. Click the Security tab, click Add and, in Enter the object names to select, type the user or group you want to make a Certificate Manager, and then click OK.
  5. In the Permissions for Added User or Group box, for Issue and Manage Certificates, select the Allow check box.

Notes

  • XOX
  • XOX

Related Topics


Add a certification authority auditor

Microsoft Windows Graphic

To add a certification authority auditor

  1. Open Local Security Settings.
  2. In the console tree, click User Rights Assignment.

    Where?

    • Security Settings
    • Local Policies
    • User Rights Assignments
  3. In the details pane, double-click Manage auditing and security log.
  4. Click Add User or Group.
  5. In Enter the object names to select (examples), type the name of the user or group you want to make an auditor, then click OK.

Notes

  • XOX
  • XOX

Related Topics


Add a certification authority backup operator

Microsoft Windows Graphic

To add a certification authority backup operator

  1. Open Local Security Settings.
  2. In the console tree, click User Rights Assignment.

    Where?

    • Security Settings
    • Local Policies
    • User Rights Assignments
  3. In the details pane, double-click Back up file and directories.
  4. Click Add User or Group and, in Enter the object names to select, type the name of the user or group to add as a backup operator, and then click OK.
  5. In the details pane, double-click Restore file and directories.
  6. Click Add User or Group and, in Enter the object names to select (examples), type the name of the user or group to add as a backup operator, and then click OK.

Notes

  • XOX
  • XOX

Related Topics


Enable role separation

Microsoft Windows Graphic

To enable role separation

Caution

  • Before enabling role separation, make certain that no user is assigned to more than one role. If a user is assigned to more than one role and role separation is enabled, then the user will not be permitted to perform any activity for the Certificate Services service. For more information, see Role-based administration.
  1. Open Command Prompt.
  2. Type:

    3. certutil -setreg ca\RoleSeparationEnabled 1

  3. Open Certification Authority.
  4. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  5. On the Action menu, point to All Tasks, and click Stop Service to stop the service.
  6. On the Action menu, point to All Tasks, and click Start Service to start the service.
Value | Description
certutil | Specifies the name of the command-line program.
-setreg | Modifies the registry.
ca\RoleSeparationEnabled | Indicates the registry value for role separation.
1 | Specifies a value for the registry entry. A value of 1 enables role separation.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

Notes

  • XOX
  • XOX
  • XOX
  • Once role separation is enabled, a local Administrator will not be able to perform any role-based administration of the CA. This is because the local Administrator account has both the CA Backup Operator and CA Auditor user rights.
  • You can assign certification authority roles for role-based administration on servers running any version of the Windows Server 2003 family, but you can only enable role separation on servers running XOX and XOX, including the 64-bit version of XOX and 64-bit version of XOX.
  • To display the role separation setting, type:

    certutil -getreg ca\RoleSeparationEnabled

  • To view the complete syntax for this command, at a command prompt, type:

    certutil -setreg -?

  • To stop and restart the Certificate Services service at the command prompt, type:

    • net stop certsvc

    net start certsvc

Related Topics


Disable role separation

Microsoft Windows Graphic

To disable role separation

  1. Open Command Prompt.
  2. Type:

    3. certutil -delreg ca\RoleSeparationEnabled

  3. Open Certification Authority.
  4. In the console tree, click the name of the certification authority (CA).

    Where?

    • Certification Authority (Computer)
    • CA name
  5. On the Action menu, point to All Tasks, and click Stop Service to stop the service.
  6. On the Action menu, point to All Tasks, and click Start Service to start the service.
Value | Description
certutil | Specifies the name of the command-line program.
-delreg | Modifies the registry.
ca\RoleSeparationEnabled | Indicates the registry value for role separation.

Caution

  • Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on your computer.

Notes

  • XOX
  • XOX
  • To display the role separation setting, type the following at a command prompt:

    certutil -getreg ca\RoleSeparationEnabled

  • To view the complete syntax for this command, at a command prompt, type:

    certutil -delreg -?

  • To stop and restart the Certificate Services service at the command prompt, type:

    • net stop certsvc

    net start certsvc

Related Topics


Concepts

Certificate Services and the Certification Authority snap-in provide a way for organizations to set up and manage a certification authority (CA) on a server for use in a public key infrastructure (PKI).

  • Public key infrastructure
  • Certificate Services overview
  • New features in Certificate Services
  • Understanding Certificate Services
  • Using Certificate Services
  • Resources


Public key infrastructure

Computer networks are no longer closed systems in which a user's mere presence on the network can serve as proof of identity. In this age of information interconnection, an organization's network may consist of intranets, Internet sites, and extranets—all of which are potentially susceptible to access by unauthorized individuals who intend to maliciously view or alter an organization's digital information assets.

There are many potential opportunities for unauthorized access to information on networks. A person can attempt to monitor or alter information streams such as e-mail, electronic commerce transactions, and file transfers. Your organization may work with partners on projects of limited scope and duration, with employees whom you know nothing about, but who, nonetheless, must be given access to some of your information resources. If your users have a multitude of passwords to remember for accessing different secure systems, they may choose weak or common passwords to more easily remember them. This not only provides an intruder with a password that is easy to crack, but also one that will provide access to multiple secure systems and stored data.

How can a system administrator be sure of the identity of a person accessing information and, given that identity, control which information that person has access to? Additionally, how can a system administrator easily and securely distribute and manage identification credentials across an organization? These are issues that can be addressed with a well-planned public key infrastructure.

A public key infrastructure (PKI) is a system of digital certificates, certification authorities (CAs) and other registration authorities (RAs) that verify and authenticate the validity of each party that is involved in an electronic transaction through the use of public key cryptography. Standards for PKIs are still evolving, even as they are being widely implemented as a necessary element of electronic commerce. For detailed information about planning a PKI and using public key cryptography, see Resources on public key infrastructure.

There are a number of reasons why an organization may choose to deploy a PKI using Windows:

  • Strong security. You can have strong authentication with smart cards. You can also maintain confidentiality and the integrity of transmitted data on public networks by using Internet Protocol security and the confidentiality of stored data by using EFS (encrypting file system).

  • Simplified administration. Your organization can issue certificates and in conjunction with other technologies eliminate the use of passwords. You can revoke certificates as necessary and publish certificate revocation lists (CRLs). There is the ability to use certificates to scale trust relationships across an enterprise. You can also take advantage of Certificate Services integration with the Active Directory directory service and policy. The capability to map certificates to user accounts is also available.

  • Additional opportunities. You can exchange files and data securely over public networks, such as the Internet. You have the ability to implement secure e-mail using Secure Multipurpose Internet Mail Extensions (S/MIME) and secure Web connections using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). You can also implement security enhancements to wireless networking.

The Windows Server 2003 family has features to help your organization implement a public key infrastructure include:

  • Certificates. A certificate is basically a digital statement issued by an authority that vouches for the identity of the certificate holder. A certificate binds a public key to the identity of the person, computer, or service who holds the corresponding private key. Certificates are used by a variety of public key security services and applications that provide authentication, data integrity and secure communications across networks such as the Internet.

    The standard certificate format used by Windows certificate-based processes is X.509v3. An X.509 certificate includes information about the person or entity to whom the certificate is issued, information about the certificate, plus optional information about the certification authority issuing the certificate. Subject information may include the entity's name, the public key, and the public-key algorithm.

    Users can manage certificates using the Certificates MMC console. For more information, see Certificates overview. Users can also allow certificate autoenrollment to manage their certificates automatically. For more information, see Planning for autoenrollment deployment.

  • Certificate Services. On XOX; XOX; and XOX, Certificate Services is the component that is used to create and manage certification authorities (CAs). A CA is responsible for establishing and vouching for the identity of certificate holders. A CA also revokes certificates if they should no longer be considered valid and publishes certificate revocation lists (CRLs) to be used by certificate verifiers. The simplest PKI design has only one root CA. In practice, however, the majority of organizations deploying a PKI will use a number of CAs, organized into certification hierarchies.

    Administrators can manage Certificate Services using the Certification Authority MMC console. For more information, see Certificate Services overview.

  • Certificate templates. Certificates are issued by the CA based on information provided in the certificate request and settings contained in a certificate template. A certificate template is the set of rules and settings that are applied against incoming certificate requests. For each type of certificate that an enterprise CA can issue, a certificate template must be configured.

    Certificate templates are customizable in XOX and XOX enterprise CAs, and are stored in Active Directory for use by all CAs in the forest. This allows the administrator to choose one or more of the default templates installed with Certificate Services or to create templates that are customized for specific tasks or roles.

    Administrators can manage Certificate Templates using the Certificate Templates MMC console. For more information, see Certificate Templates.

  • Certificate autoenrollment. Autoenrollment allows the administrator to configure subjects to automatically enroll for certificates, retrieve issued certificates, and renew expiring certificates without requiring subject interaction. This requires no knowledge by the subject of any certificate operations, unless the certificate template is configured to interact with the subject or the CSP requires interaction (such as with a smart card CSP). This greatly simplifies the experience of the client with certificates and minimizes administrative tasks.

    Administrators can configure autoenrollment through configuration of Certificate Templates and CA settings. For more information see Planning for autoenrollment deployment.

  • Web enrollment pages. These are a separate component of Certificate Services. These Web pages are installed by default when you set up a CA and allow certificate requesters to submit certificate requests using a Web browser. Additionally, the CA Web pages can be installed on servers running Windows that do not have a certification authority installed. In this case, the Web pages are used to direct certificate requests to a CA that, for whatever reason, you do not want requesters to directly access. If you choose to create custom Web pages for your organization to access a CA, the Web pages provided in your operating system can be used as samples. Refer to the Microsoft Platform Software Development Kit for information about customizing Certificate Services and CA Web pages.

  • Smart card support. Windows supports logon via certificates on smart cards, as well as the use of smart cards to store certificates and private keys. They can be used for Web authentication, secure e-mail, wireless networking and other public key cryptography-related activities. For more information, see Smart Cards.

  • Public key policies. You can use Group Policy in Windows to distribute certificates to subjects automatically, establish common trusted certification authorities, as well as managing recovery policies for EFS (Encrypting File System). For more information, see Public Key Policies overview


Certificate Services overview

Certificate Services provides customizable services for issuing and managing certificates used in software security systems employing public key technologies. For background information about public key cryptography and the benefits of having a public key infrastructure (PKI), see Public key infrastructure.

You can use Certificate Services in the Windows® operating system to create a certification authority (CA) which will receive certificate requests, verify the information in the request and the identity of the requester, issue certificates, revoke certificates, and publish a certificate revocation list (CRL).

For more information about CAs, see Certification authorities

Certificate Services can also be used to:

  • Enroll users for certificates from the CA using the Web or the Certificates Microsoft Management Console (MMC) snap-in, or transparently through autoenrollment.
  • Use certificate templates to help simplify the choices a certificate requester has to make when requesting a certificate, depending upon the policy used by the CA.
  • Take advantage of the Active Directory® directory service for publishing trusted root certificates, publishing issued certificates, and publishing CRLs.
  • Implement the ability to log on to a Windows operating system domain using a smart card.

Certificate policy

A certificate policy is a set of instructions or rules that are used when processing certificate requests, issuing certificates, revoking certificates, and publishing CRLs. These instructions are a combination of administrative policy and configuration settings on the CA.

When you install Certificate Services, the CA is configured with a default set of rules and settings. These define CA-specific settings such as the CA's certificate, its default issuance behavior, and its key recovery agents. The CA may also install a number of preconfigured certificate templates, which define what information a certificate request must have and how to process incoming requests for a certificate based on that template. The combination of applying CA settings and certificate template settings, plus the defined administrative guidelines, results in the certificate policy that governs the operation of a CA.

Processing certificate requests

A user can request certificates using Microsoft® Internet Explorer 5.0 or later or a browser such as Netscape Navigator 4.7x or later. In addition, a user can use the Certificates snap-in to request a certificate from an enterprise CA or an administrator can configure certificate autoenrollment to transparently request and install certificates for users.

When a user initiates a certificate request, a cryptographic service provider (CSP) on their computer generates a public key and private key pair for the user. The user's public key is sent with their necessary identifying information to the CA. If the user's identifying information meets the CA criteria for granting a request, the CA generates the certificate, which is retrieved by the client application and stored locally. For more information about certificates, see Understanding Certificates.

Security considerations for CAs

CAs are valuable resources, and you should provide them with a high degree of protection. Specific actions that should be considered include:

  • Physical protection. Since CAs represent highly-trusted entities within an enterprise, you should protect them from tampering, depending on the inherent value of the certification made by the CA. Physical isolation of the CA server, in a facility accessible only to security administrators, can dramatically reduce the possibility of such attacks.
  • Restoration. A CA might be lost if there is a hardware failure. This can create a number of administrative and operational problems, and can prevent revocation of existing certificates. Certificate Services supports the backup of a CA using Backup so that it can be restored at a later time. This is an important part of the overall CA management process.
  • Key management. The CA's keys are its most valuable asset, because the private key provides the basis for trust in the certification process. Cryptographic hardware modules can provide tamper-resistant key storage and isolate the cryptographic operations from other software running on the server. This reduces the likelihood of a CA key being compromised. Certificate Services supports cryptographic service providers (CSPs) from other sources, but the documentation included with Windows is specific to the software CSPs that are included with Windows. If you use a CSP from another source, you should confirm with the vendor that the CSP can work with Certificate Services.

Customizing Certificate Services

Certificate Services includes programmable interfaces so that developers can create support for additional transports, policies, and certificate properties and formats. Refer to the Microsoft Platform Software Development Kit for information about customizing Certificate Services.

For more information about Certificate Services, see Understanding Certificate Services


New features in Certificate Services

XOX; XOX; and XOX have a number of new features and improvements related to Certificate Services and public key infrastructure (PKI). A few new procedures are also provided to demonstrate certificate template editing features and certificate autoenrollment for users and computers.

New PKI features

XOX; XOX; and XOX implement new PKI features and improvements.

  • Editable certificate templates and the Certificate Templates MMC snap-in

    Certificate templates were available in Windows 2000 Certificate Services, but they could not be modified or changed. There is a new Certificate Templates MMC snap-in that enables administrators to:

    • Create a new certificate template by duplicating and renaming an existing template.
    • Modify template properties such as certificate validity period, renewal period, cryptographic service provider (CSP), key size, key archival
    • Establish and apply enrollment policies, issuance policies and application policies.

      For example, in Windows 2000, a user can enroll themselves for a certificate or an enrollment agent certificate can enroll for a certificate on their behalf. A significant issue with this scenario is that an enrollment agent can enroll for any user in the enterprise. This means the enrollment agent certificate is very powerful and only very trusted people may have access to it. However, there are many scenarios where it is necessary to restrict which account an enrollment agent can request. For example, a manager may need to be able to enroll their reports or a local administrator may need to be able to issue smart card for people in his building. It is possible to delegate who may approve a certificate enrollment and whom an enrollment agent may enroll.

    • Allow for autoenrollment for certificates based on the template.
    • Set access control on certificate templates to establish which users or computers can enroll and autoenroll for certificates.

    There are now two different versions of certificate templates for Windows server operating systems. Windows 2000 clients and certificate services can only use version 1 templates. XOX and Windows Server 2003 family clients and certificate services will support both version 1 and version 2 templates. Version 1 templates are read-only, but when they are duplicated, the duplicate template is an editable version 2 template.

  • Certificate autoenrollment and autorenewal for all subjects

    In Windows 2000, it was possible to autoenroll for EFS certificates and computer certificates, however, autoenrollment for users was not possible. The new autoenrollment feature improves both the user and computer enrollment experience. A member of the Enterprise Admins group can specify the types of certificates that any entity should automatically be issued. The enterprise administrator controls autoenrollment by setting security permissions on certificate templates using the Certificate Templates snap-in. A XOX or Windows Server 2003 family client then accesses the templates in the Active Directory directory service and, if access has been granted, then it will enroll for those certificates.

    For an example of establishing autoenrollment for user certificates, see Certificate Services example implementation: Establishing autoenrollment for user certificates.

    Autorenewal is a new feature similar to autoenrollment and the same mechanism on the templates is used to control who can autorenew a certificate. Every certificate in the certificate store that has a template extension can potentially be autorenewed by the system. This means that applications no longer need to worry about certificates expiring.

  • Delta CRLs

    Many applications require up-to-date certificate revocation status information. This requires the certification authority (CA) to frequently publish a new certificate revocation list (CRL). A CRL is the entire list of revoked certificates, so for a CA with a large amount of issued certificates, this can become a very large list. Even if there are no changes, a CA has to republish the entire list so that applications have the latest information, which involves a lot of repetition. Frequent publication of large objects will in turn generates a large amount of replication traffic.

    XOX; XOX; and XOX have a new feature called delta CRLs, an option in RFC 2459. Delta CRLs are CRLs which contain the list of changes in revocation status from a full "base" CRL. Because delta CRLs are a list of changes and not a restatement of the entire CRL, they are typically much smaller and generate significantly less replication traffic than large base CRLs.

  • Role-based administration

    Certificate Services in XOX; XOX; and XOX allows for the separation of roles for the management and maintenance of a CA. Role separation is not enforced by default, but you can select to enforce assigned roles.

    For more information, see Role-based administration.

  • Key archival and recovery

    You can configure a CA to archive the keys associated with the certificates it issues. If necessary, you can then recover lost keys through the use of a key recovery agent certificate.

    For more information, see Certificate Services example implementation: Key archival and recovery.

  • Event auditing

    Event auditing provides the ability to log most events that occur on a CA. This can be useful for monitoring the activities of a CA or the administrative functions, such as certificate issuance and role changes.

    For more information, see Configure event auditing.

  • Qualified subordination

    Qualified subordination is an extension of standard CA subordination that allows you to:

    • Define the namespaces for which a subordinate CA will issue certificates.
    • Specify the acceptable uses of certificates issued by a qualified subordinate CA.
    • Enable a certificate to be used in separate certification hierarchies.

    For more information, see Qualified subordination.

  • New Certutil.exe commands

    certutil -dspublish [cert|crl]
    Publishes the CA certificate or the certificate revocation list to Active Directory
    For examples of using certutil -getkey and certutil -recoverkey to recover archived keys, see Certificate Services example implementation: Key archival and recovery.


Understanding Certificate Services

This section covers:

  • Processing certificate requests
  • Certificate revocation
  • Key archival and recovery
  • Certificate templates
  • Policy and exit modules
  • Certification authority hierarchies
  • Certification authority database
  • Certification authority Web enrollment services
  • Interoperability in Certificate Services
  • Role-based administration
  • Certification authorities


Processing certificate requests

A certification authority (CA) performs the following operations when processing a certificate request:

  • Request reception. The certificate request is sent by the client application (such as the Certificate Request Wizard in the Certificates snap-in), which formats it into a PKCS #10 or CMC format request and submits it to the CA. On receipt, the CA server engine stores the private key in its certificate database if it is configured for key recovery.
  • Request approval. The CA server engine calls the CA policy module, which queries the request properties, decides whether the request is authorized or not, and sets optional certificate properties. If the request is denied or set to Pending, the requestor is notified.
  • Certificate formation. If the request is approved, the CA server engine takes the request and any properties requested by the policy module, and then builds a complete certificate.
  • Certificate publication. The CA server engine stores the completed certificate in its certificate database and notifies the intermediary application of the request status. If the exit module has requested it, the server engine notifies it of a certificate issuance event. This allows the exit module to perform further operations, such as sending e-mail to the subject or the CA administrator. Meanwhile, the client application gets the issued certificate from the certificate database and saves it in its own local certificate store.


Certificate revocation

Revocation of a certificate invalidates a certificate as a trusted security credential prior to the natural expiration of its validity period. There are a number of reasons why a certificate, as a security credential, could become untrustworthy prior to its expiration. Examples include:

  • Compromise, or suspected compromise, of the certificate subject's private key.
  • Compromise, or suspected compromise, of a certification authority's private key.
  • Discovery that a certificate was obtained fraudulently.
  • Change in the status of the certificate subject as a trusted entity.
  • Change in the name of the certificate subject.

A public key infrastructure (PKI) depends on distributed verification of credentials in which there is no need for direct communication with the central trusted entity that vouches for the credentials. This creates a need to distribute certificate revocation information to individuals, computers, and applications attempting to verify the validity of certificates. The need for revocation information and its timeliness will vary, according to the application and its implementation of certificate revocation checking.

To effectively support certificate revocation, the client must determine whether the certificate is valid or has been revoked. To support a variety of scenarios, Certificate Services supports industry-standard methods of certificate revocation. These include publication of certificate revocation lists (CRLs) and delta CRLs in several locations for clients to access, including the Active Directory directory service, Web servers, and network file shares.

CRLs are complete, digitally-signed lists of unexpired certificates that have been revoked. This list is retrieved by clients who can then cache it (based on the configured lifetime of the CRL) and use it to verify certificates presented for use. Because CRLs can get large, depending on the size of the certification authority, delta CRLs can also be published. Delta CRLs contain only the certificates revoked since the last base CRL was published. This allows clients to retrieve the smaller delta CRL and quickly build a complete list of revoked certificates. The use of delta CRLs also allows more frequent publishing, because the size of the delta CRL usually does not require as much overhead as a full CRL.

For conceptual information about using certificate revocation in Certificate Services, see Revoking certificates and publishing CRLs. For procedures to manage certificate revocation, see Manage Certificate Revocation.


Key archival and recovery

XOX can be configured to archive the private key of specific certificates when they are issued. This private key archive allows the key to be recovered at a later time if the private key is lost. This process is implemented in two separate phases: key archival and key recovery.

Key archival

The process of obtaining a certificate includes the subject locating the appropriate certificate template, gathering the information required by that template, and supplying it to a certification authority. This information normally contains information such as the subject name, public key and supported cryptographic algorithms. When key archival is configured, the subject will also provide their private key to the certification authority. The certification authority stores that private key in its database until you want to perform key recovery.

By default, the private key of issued certificates is not archived. This is because the storage of the private key in multiple locations, by definition, allows more attacks against it. To configure a certification authority to issue certificates with key archival enabled, see Certificate Services example implementation: Key archival and recovery.

Key recovery

Subjects can lose their private key in a variety of ways such as accidental deletion or deliberate misuse. An administrator may also want to recover the key of a particular subject to access data protected by that key. Key recovery can be used whenever the key archival process has stored the subject's private key.

The key recovery process requires an administrator to retrieve the encrypted certificate and private key and then a key recovery agent (KRA) to submit to the certification authority. When a correctly signed key recovery request is received, the subject's certificate and private key are provided to the requestor. The requestor would then use the key as appropriate or securely transfer the key to the subject for continued use. No recertification or rekeying is necessary, as the private key is not necessarily compromised.

For more information, see Manage key archival and recovery.


Certificate templates

A certificate template profiles certificates based on their intended use. When requesting a certificate from a Microsoft certification authority (CA), the certificate requester will, depending on their access rights, be able to select from a variety of certificate types that are based on certificate templates, such as User and Basic EFS. The certificate template saves users from low-level, technical decisions about the type of certificate that they need. Instead, they can rely on the judgment of their administrators and use the template name that indicates the purpose of the certificate. If none of the preset certificate templates meet your needs, you can create new certificate templates and customize them for a variety of different uses.

For more information, see Certificate Templates.


Policy and exit modules

One powerful administrative feature of Certificate Services is the ability to control and customize the behavior of the certification authority (CA) through the use of policy and exit modules.

Policy modules can determine whether a certificate request should be automatically approved, denied, or marked as Pending. Exit modules provide an opportunity to perform post-processing after a certificate is issued.

Certificate Services comes with one exit module (Certxds.dll) and one policy module (Certpdef.dll). The policy module includes two separate policies: enterprise and stand-alone. To compare a CA using enterprise policy and a CA using stand-alone policy, see Enterprise certification authorities and Stand-alone certification authorities.

As a CA administrator, you can replace these default modules with your own custom policy and exit modules or commercial policy and exit modules. In addition, if you have upgraded to XOX; XOX; or XOX Certificate Services from an earlier version of Certificate Services, you will have the option of using the policy module you have been using prior to upgrading. It will either be listed as a legacy policy module when you look at the properties of the CA or with its original name, depending on how it was created.

The policy module provided with the Microsoft CA performs the following function:

  • Determines the default action of a certification authority upon receiving a certificate request. Upon receiving a certificate request, a certification authority can either automatically issue a certificate or hold it as Pending until an administrator reviews the request.

    Microsoft certification authorities can either issue a certificate automatically upon receiving a request or hold the request as Pending. In the majority of instances, the administrator of a stand-alone CA will want to have all incoming certificate requests set to Pending. Otherwise, because the stand-alone CA does not verify the identity of requesters via the Active Directory directory service, there is no way to verify the identity and validity of the certificate requester.

The CA can only have one policy module loaded at a time. The Windows 2000 CA policy module contained a great deal of functionality that has been integrated into the core certification authority functionality. This allows the policy module to be more easily replaced without losing functionality.

The exit module that is provided with the Microsoft CA performs the following functions:

  • Sends e-mail when a certification event occurs. If the CA is configured to send e-mail when specific events occur, the exit module will do so.
  • Allows certificate publication to the file system. If the certificate request specifies a location to publish the certificate in the file system, the exit module will do so.

Please note that this is not an exhaustive list of the functions of the exit module. Unlike the policy module, multiple exit modules can be used by a CA simultaneously.

To configure the settings of the default policy and exit modules, see Configuring the policy and exit modules. To configure e-mail sending options, see Send e-mail when a certification event occurs.

Customizing Certificate Services policy and exit modules

Programmable interfaces are included in Certificate Services for developers to create customized policy modules. For more information, refer to the Microsoft Platform Software Development Kit.

If you have created a customized policy module using the guidelines in the Microsoft Platform Software Development Kit and you want to change the policy module, see Select a different policy module.

If you have created a customized exit module using the guidelines in the Microsoft Platform Software Development Kit and you want to change or add an exit module, see Select a different exit module.


Certification authority hierarchies

The Microsoft public key infrastructure (PKI) supports a hierarchical certification authority (CA) model. A certification hierarchy provides scalability, ease of administration, and consistency with a growing number of commercial and other CA products.

In its simplest form, a certification hierarchy consists of a single CA. However, in general, a hierarchy will contain multiple CAs with clearly defined parent-child relationships. In this model, the child subordinate certification authorities are certified by their parent CA-issued certificates, which bind a certification authority's public key to its identity. The CA at the top of a hierarchy is referred to as the root authority, or root CA. The child CAs of the root CAs are called subordinate certification authorities (CAs).

In XOX and the Windows Server 2003 family, if you trust a root CA (by having its certificate in your Trusted Root Certification Authorities certificate store), you trust every subordinate CA in the hierarchy, unless a subordinate CA has had its certificate revoked by the issuing CA or has an expired certificate. Thus, any root CA is a very important point of trust in an organization and should be secured and maintained accordingly.

Verification of certificates thus requires trust in only a small number of root CAs. At the same time, it provides flexibility in the number of certificate-issuing subordinate CAs. There are several practical reasons for supporting multiple subordinate CAs, including:

  • Usage. Certificates may be issued for a number of purposes, such as secure e-mail and network authentication. The issuing policy for these uses may be distinct, and separation provides a basis for administering these polices.
  • Organizational divisions. There may be different policies for issuing certificates, depending upon an entity's role in the organization. Again, you can create subordinate CAs to separate and administer these policies.
  • Geographic divisions. Organizations may have entities at multiple physical sites. Network connectivity between these sites may dictate a requirement for multiple subordinate CAs to meet usability requirements.
  • Load balancing. If your PKI is going to support the issuing of a large number of certificates, having only one certification authority issue and manage all of these certificates can result in considerable network load for that single certification authority. Using multiple subordinate certification authorities to issue the same kind of certificates divides the network load between certification authorities.
  • Backup and fault tolerance. Multiple certification authorities increase the possibility that your network will always have operational certification authorities available to service users.

Such a certification authority hierarchy also provides administrative benefits, including:

  • Flexible configuration of the CA security environment to tailor the balance between security and usability, such as key strength, physical protection, and protection against network attacks. For example, you may choose to employ special purpose cryptographic hardware on a root CA, operate it in a physically secure area, or operate it offline. These may be unacceptable for subordinate CAs, due to cost or usability considerations.
  • The ability to "turn off" a specific portion of the CA hierarchy without affecting the established trust relationships. For example, you can easily shut down and revoke an issuing CA certificate that is associated with a specific geographic site without affecting other parts of the organization.

For more information, see Establishing a certification hierarchy


Certification authority database

When you install a certification authority (CA), you create a certification authority database on the server. This database should be located on an NTFS file system partition on the server's disk drives to provide the best security possible for the database file. You specify the locations for the database during the setup of a CA. By default, the database is located in:

systemroot\system32\certlog

The name of the database file is based on the name of the CA, with an .edb extension.

The Certification Authority MMC console provides a view into the certification authority database on a CA and the ability to administer the database.

A certification authority database stores:

  • Every certificate issued by the CA.
  • Every private key archived by the CA.
  • Every certificate revoked by the CA.
  • Every certificate request received by the CA, regardless of the disposition.

You also specify the location of the certificate database log during Certificate Services setup. The certificate database log keeps a record of every transaction involving the certificate database. Certificate database logs are used when restoring the CA from a backup. If a CA is restored from a backup that is one month old, then the certification database logs that have been generated since the last backup can be replayed against the database to restore it to its most current state. When you back up a certification authority, the existing certificate database logs will be truncated in size, because they will no longer be needed to restore the certificate database to its most current state.

For more information about CA backup and restore, see Backing up and restoring a certification authority.


Certification authority Web enrollment services

A set of certification authority (CA) Web pages is provided with Certificate Services in XOX; XOX; and XOX. These Web pages provide a simple user interface to perform many of the common user tasks on a CA, and they are installed by default when you set up Certificate Services.

These Web enrollment pages allow you to connect to the CA via a Web browser and perform common tasks, such as requesting certificates from a CA, requesting the CA's certificate, submitting a certificate request using a PKCS #10 file, retrieving the CA's certificate revocation list (CRL) or performing smart card certificate enrollment. For a stand-alone CA, the Web pages are the primary way a certificate requester can interface with the CA, since the Certificates snap-in cannot be used to request certificates from a stand-alone CA. Enterprise CAs can accept certificate requests via the Certificates snap-in or the Web enrollment pages.

You can install Web enrollment pages for a CA on a Windows Server 2003 family server that is not a CA in order to divert Web-based traffic from the actual CA. For more information about installing the Web pages on a server that is not a CA, see Set up certification authority Web enrollment support. You can also configure your Web server to use Secure Sockets Layer (SSL) encryption to protect the network traffic that contains the enrollment request and response. This is especially important when clients are using Windows 95, Windows 98, Windows Millennium Edition and Windows 2000 because of their handling of certificates.

For more information about using the Web enrollment pages, see Using Windows 2000 Certificate Services Web pages or Using Windows Server 2003 Certificate Services Web pages.


Interoperability in Certificate Services

By using industry-standard X.509v3 certificate formats and open interfaces, Certificate Services operates with many products and technologies that support the use of public key cryptography and public key infrastructure (PKI).

Internet standards

PKI standards for the Internet are still evolving as this is being written. However, Certificate Services has been designed to adhere to existing PKI interoperability standards established by the Internet Engineering Task Force (IETF). The IETF working group charged with defining the basis for an interoperable PKI is PKIX. For more information on PKIX, see the PKIX Web page. The Web page also has a link to RFC 2459, "Internet Public Key Infrastructure X.509 Certificate and CRL Profile, Part 1," which is the specification for the basic architecture of PKI.

Public Key Cryptography Standards

There is a set of de facto cryptographic message standards called Public Key Cryptography Standards (PKCS) which are developed and maintained by RSA Laboratories. (For more information, see the Web page at RSA Laboratories.)

PKCS provides a basic, but well-understood framework for interoperability. The standards that are most relevant to PKI and ones that are used by Certificate Services are PKCS #7, Cryptographic Message Syntax Standard, PKCS #10, Certification Request Syntax Standard, and PKCS #12, Personal Information Exchange Syntax Standard.

Web servers

On a corporate intranet or on the Internet, Web servers, such as those using Microsoft Internet Information Services (IIS), can perform client authentication for secure communications using certificates generated by Certificate Services. Certificate Services can also generate server certificates used by IIS and other Web servers to provide server authentication to assure clients that they are communicating with the intended entity.

Web browsers

Certificate Services can issue certificates that are used by Web browsers that support client authentication, such as Microsoft Internet Explorer 5.0 or later. Certificate Services also supports Web enrollment, where a Web browser uses Web pages to request and retrieve a certificate.

Windows

Windows enables you to map certificates to users and groups. This mapping is automatic if the certificate is issued from an enterprise certification authority (CA). You can then use standard Windows administrative tools, such as security permission sets, to implement Internet and intranet security requirements taking advantage of the relationship established between domain users and the certificates issued to them.

For more information about mapping certificates in Windows see Mapping certificates to user accounts.

Note

  • XOX


Role-based administration

You can use role-based administration to organize your certification authority (CA) administrators into separate, predefined CA roles, each with its own set of tasks. Roles are assigned using each user's security settings. You assign a role to a user by assigning that user the specific security settings that are associated with the role. A user that has one type of permission, such as Manage CA permission, can perform specific CA tasks that a user with another type of permission, such as Issue and Manage Certificates permission, cannot perform. For more information, see Role explanation.

Note

  • Role-based administration is supported by both Windows Server 2003 enterprise and stand-alone certification authorities. For information about using Windows 2000 Server certification authorities and role-based administration, see Windows 2000 roles and Windows Server 2003 role-based administration.

Role explanation

Role-based administration involves CA roles, users, and groups. To assign a role to a user or group, you must assign the role's corresponding security permissions, group memberships, or user rights to the user or group. These security permissions, group memberships, and user rights are used to distinguish which users have which roles. The following table describes the CA roles of role-based administration and the groups relevant to role-based administration.

Roles and groups | Security permission | Description
CA Administrator | Manage CA permission | Configure and maintain the CA. This is a CA role and includes the ability to assign all other CA roles and renew the CA certificate.
Certificate Manager | Issue and Manage Certificates permission | Approve certificate enrollment and revocation requests. This is a CA role. This role is sometimes referred to as CA Officer.
Backup Operator | Back up file and directories and Restore file and directories permissions | Perform system backup and recovery. This is an operating system role.
Auditor | Manage auditing and security log permission | Configure, view, and maintain audit logs. This is an operating system role.
Enrollees | Authenticated Users | Enrollees are clients who are authorized to request certificates from the CA. This is not a CA role.

All CA roles are assigned and modified by local Administrators, Enterprise Admins, and Domain Admins. Local Administrators, Enterprise Admins, and Domain Admins are CA Administrators by default on an Enterprise CA. Only local Administrators are CA Administrators by default on a stand-alone CA. If the stand-alone CA is logged on to an Active Directory domain, Domain Admins are also CA Administrators.

The CA Administrator and Certificate Manager roles can be assigned to both Active Directory users or local users in the Security Accounts Manager (SAM) of the local computer, which is the local security account database. As a best practice, assign roles to group accounts instead of individual user accounts.

Only CA Administrator, Certificate Manager, Auditor, and Backup Operator are CA roles. The other users described in the table are relevant to role-based administration and should be understood before assigning CA roles.

Only CA Administrators and Certificate Managers are assigned using the Certification Authority Microsoft Management Console (MMC) snap-in. Other roles, users, and groups are specified in their related consoles. To change the roles of a user, you must change the user's security permissions, group membership, or user rights. For information about assigning roles, see Assigning roles.

When key archival is configured, the subject obtaining a certificate from a CA will provide their private key to the CA. The CA stores that private key in its database until key recovery. Only a Certificate Manager can get the encrypted private key blob out of the CA database, which is then passed on to key recovery agents (KRAs). For more information, see Key archival and recovery.

Roles and activities

Each CA role has a specific list of CA administration tasks associated with it. The following table lists all the CA administration tasks along with the roles in which they are performed.

Role and activities table

Activity | CA Administrator | Certificate Manager | Auditor | Backup Operator | Local Administrator | Notes
Install CA |  |  |  |  | X |
Configure policy and exit module | X |  |  |  |  |
Stop and start the Certificate Services service | X |  |  |  |  |
Configure extensions | X |  |  |  |  |
Configure roles | X |  |  |  |  |
Renew CA keys |  |  |  |  | X |
Define key recovery agents | X |  |  |  |  |
Configure Certificate Managers restrictions | X |  |  |  |  |
Delete single row in database | X |  |  |  |  |
Delete multiple rows in database (bulk deletion) | X | X |  |  |  | The user must be both a CA Administrator and a Certificate Manager. This does not work when Role Separation is enforced.
Enable role separation |  |  |  |  | X |
Issue and approve certificates |  | X |  |  |  |
Deny certificates |  | X |  |  |  |
Revoke certificates |  | X |  |  |  |
Reactivate certificates placed on hold |  | X |  |  |  |
Renew certificates |  | X |  |  |  |
Enable, publish, or configure CRL schedule | X |  |  |  |  |
Recover archived key |  | X |  |  |  | Only a Certificate Manager can retrieve the encrypted key data structure from the database. The private key of a valid Key Recovery Agent is required to decrypt the key data structure and generate a PKCS#12 file.
Configure audit parameters |  |  | X |  |  | By default, the local Administrator holds the system audit user right.
Audit logs |  |  | X |  |  | By default, the local Administrator holds the system audit user right.
Back up system |  |  |  | X |  | By default, the local Administrator holds the system backup user right.
Restore system |  |  |  | X |  | By default, the local Administrator holds the system backup user right.
Read CA database | X | X | X | X |  | By default, the local Administrator holds the system audit and backup user rights.
Read CA configuration information | X | X | X | X |  | By default, the local Administrator holds the system audit and backup user rights.

Notes

  • Enrollees are allowed to read CA properties and certificate request lists (CRLs), and can request certificates. On an Enterprise CA, a user must have Read and Enroll permissions on the certificate template to request a certificate. For more information, see Allow subjects to request a certificate based on the template.
  • CA Administrators, Certificate Managers, Auditor, and Backup Operators have implicit Read permissions.
  • An Auditor holds the system audit user right.
  • A Backup Operator holds the system backup user right. In addition, the Backup Operator has the ability to start and stop the Certificate Services service.

Assigning roles

The CA Administrator for a CA assigns users to the separate roles of role-based administration by giving each user the security settings required by a role. The CA Administrator can assign a user to more than one role, but the CA is more secure when each user belongs to one role only. When each CA role belongs to one user only, then there are fewer CA tasks that can be compromised if a user's account becomes compromised.

For more information on assigning roles, see Managing role-based administration.

Administrator concerns

The default installation setting for a stand-alone CA is to have members of the local Administrators security group as CA Administrators. The default installation setting for an Enterprise CA is to have local Administrators, Enterprise Admins, and Domain Admins as CA Administrators. To limit the power of any of these accounts, they should be removed from the CA Administrator and Certificate Manager roles once all CA roles are assigned.

As a best practice, group accounts that have been assigned CA Administrator or Certificate Manager roles should not be members of the local Administrators security group. Also, CA roles should only be assigned to group accounts and not individual user accounts.

Note

  • Membership in the local Administrators group on the CA is required to renew the CA certificate. Members of this group are considered to be all powerful on the CA, with administrative authority over all other CA roles.

Windows 2000 roles and Windows Server 2003 role-based administration

Windows 2000 Server CA administration is changed in XOX CA role-based administration. Windows 2000 Server administrators can perform any activity on a Windows 2000 Server CA, but once CA roles are assigned using Windows Server 2003 role-based administration, its administrators are subject to its roles. An administrator that could perform all tasks on a Windows 2000 Server CA will only be able to perform the tasks associated with his or her role on the Windows Server 2003 CA. After upgrading a Windows 2000 Server CA to a Windows Server 2003 CA, its administrators need to be assigned to the roles defined in the role-based administration for the Windows Server 2003 CA.

Certificate Services service level functionality

Role-based administration applies to the Certificate Services service only. Any services other than Certificate Services service are unaffected by the assignment of CA roles.

Role separation

The separation of CA roles can be enforced using role separation. Once enforced, role separation allows a user to be assigned only a single role. If a user is assigned to more than one role and attempts to perform an operation on the CA, the operation is denied. For this reason, before role separation is enabled, a user should be assigned only one CA role.

This feature is valuable for large enterprises where the separation of roles ensures that the compromise of a user's account does not compromise the entire CA administered by the user. For more information, see Using role separation.


Certification authorities

A certification authority (CA) is an entity entrusted to issue certificates to individuals, computers, or organizations that affirm the identity and other attributes of the certificate subject to other entities.

  • Types of certification authorities
  • Enterprise certification authorities
  • Stand-alone certification authorities
  • Qualified subordination


Types of certification authorities

A certification authority (CA) accepts a certificate request, verifies the requester's information according to the policy of the CA, and then uses its private key to apply its digital signature to the certificate. The CA then issues the certificate to the subject of the certificate for use as a security credential within a public key infrastructure (PKI). A CA is also responsible for revoking certificates and publishing a certificate revocation list (CRL).

A CA can be an outside entity, such as VeriSign, or it can be a CA that you create for use by your organization by installing Microsoft Certificate Services. Each CA can have distinct proof-of-identity requirements for certificate requesters, such as a Windows Server 2003 family domain account, employee badge, driver's license, notarized request, or physical address. Identification checks such as this often warrant an onsite CA, so that organizations can validate their own employees or members.

Microsoft enterprise CAs use a person's user account credentials as proof of identity. In other words, if you are logged on to a Windows Server 2003 family domain and request a certificate from an enterprise CA, the CA knows that you are who the Active Directory directory service says you are.

Every CA also has a certificate to confirm its own identity, issued by another trusted CA or, in the case of root CAs, issued by itself. It is important to remember than anyone can create a CA. The real question revolves around whether you, as a user or an administrator, trust that CA and, by extension, the policies and procedures that CA has in place for confirming the identity of the entities issued certificates by that CA.

For more information about certificates, see Certificates overview.

Root and subordinate certification authorities

A root CA, sometimes called a root authority, is meant to be the most trusted type of CA in an organization's PKI. Typically, both the physical security and the certificate issuance policy of a root CA are more rigorous than those for subordinate CAs; if the root CA is compromised or issues a certificate to an unauthorized entity, then any certificate-based security in your organization is suddenly vulnerable. While root CAs can be used to issue certificates to end users for such tasks as sending secure e-mail, in most organizations they will only be used to issue certificates to other CAs, called subordinate CAs.

A subordinate CA is a CA that has been certified by another CA in your organization. Typically, a subordinate CA will issue certificates for specific uses, such as secure e-mail, Web-based authentication, or smart card authentication. Subordinate CAs can also issue certificates to other, more subordinate CAs. Together, a root CA, the subordinate CAs that have been certified by the root, and subordinate CAs that have been certified by other subordinate CAs form a certification hierarchy.

For more information about certification hierarchies, see Certification authority hierarchies.

Enterprise and stand-alone certification authorities

This version of Certificate Services supports the installation of stand-alone CAs and enterprise CAs. For information about the operational characteristics of enterprise CAs and stand-alone CAs, see Enterprise certification authorities and Stand-alone certification authorities.


Enterprise certification authorities

The Enterprise Administrator can install Certificate Services to create an enterprise certification authority (CA). Enterprise CAs can issue certificates for purposes such as digital signatures, secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions), authentication to a secure Web server using Secure Sockets Layer (SSL) or Transport Layer Security (TLS), and logging on to a Windows Server 2003 family domain using a smart card.

An enterprise CA has the following features:

  • An enterprise CA requires the Active Directory directory service.
  • When you install an enterprise root CA, it uses Group Policy to propagate its certificate to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. You must be a Domain Administrator or be an administrator with write access to Active Directory to install an enterprise root CA.
  • Certificates can be issued for logging on to a Windows Server 2003 family domain using smart cards.
  • The enterprise exit module publishes user certificates and the certificate revocation list (CRL) to Active Directory. In order to publish certificates to Active Directory, the server that the CA is installed on must be a member of the Certificate Publishers group. This is automatic for the domain the server is in, but the server must be delegated the proper security permissions to publish certificates in other domains. For more information about the exit module, see Policy and exit modules.

An enterprise CA uses certificate types, which are based on a certificate template. The following functionality is possible when you use certificate templates:

  • Enterprise CAs enforce credential checks on users during certificate enrollment. Each certificate template has a security permission set in Active Directory that determines whether the certificate requester is authorized to receive the type of certificate they have requested.
  • The certificate subject name can be generated automatically from the information in Active Directory or supplied explicitly by the requestor.
  • The policy module adds a predefined list of certificate extensions to the issued certificate. The extensions are defined by the certificate template. This reduces the amount of information a certificate requester has to provide about the certificate and its intended use.

For more information, compare Stand-alone certification authorities. For more information about certificate templates, see Certificate templates. For general information about CAs, see Certification authorities.


Stand-alone certification authorities

You can install Certificate Services to create a stand-alone certification authority (CA). Stand-alone CAs can issue certificates for purposes such as digital signatures, secure e-mail using S/MIME (Secure Multipurpose Internet Mail Extensions), and authentication to a secure Web server using Secure Sockets Layer (SSL) or Transport Layer Security (TLS).

A stand-alone CA has the following characteristics:

  • Unlike an enterprise CA, a stand-alone CA does not require the use of the Active Directory directory service. Stand-alone CAs are primarily intended to be used as Trusted Offline Root CAs in a CA hierarchy or when extranets and the Internet are involved. Additionally, if you want to use a custom policy module for a CA, you would first install a stand-alone CA and then replace the stand-alone policy module with your custom policy module.
  • When submitting a certificate request to a stand-alone CA, a certificate requester must explicitly supply all identifying information about themselves and the type of certificate that is wanted in the certificate request. (This does not need to be done when submitting a request to an enterprise CA, since the enterprise user's information is already in Active Directory and the certificate type is described by a certificate template). The authentication information for requests is obtained from the local computer's Security Accounts Manager database.
  • By default, all certificate requests sent to the stand-alone CA are set to Pending until the administrator of the stand-alone CA verifies the identity of the requester and approves the request. This is done for security reasons, because the certificate requester's credentials are not verified by the stand-alone CA.
  • Certificate templates are not used.
  • No certificates can be issued for logging on to a Windows Server 2003 family domain using smart cards, but other types of certificates can be issued and stored on a smart card.
  • The administrator has to explicitly distribute the stand-alone CA's certificate to the domain user's trusted root store or users must perform that task themselves.
When a stand-alone CA uses Active Directory, it has these additional features:
  • If a member of the Domain Administrators group or an administrator with write access to Active Directory, installs a stand-alone root CA, it is automatically added to the Trusted Root Certification Authorities certificate store for all users and computers in the domain. For this reason, if you install a stand-alone root CA in an Active Directory domain, you should not change the default action of the CA upon receiving certificate requests (which marks requests as Pending). Otherwise, you will have a trusted root CA that automatically issues certificates without verifying the identity of the certificate requester.

  • If a stand-alone CA is installed by a member of the Domain Administrators group of the parent domain of a tree in the enterprise, or by an administrator with write access to Active Directory, then the stand-alone CA will publish its CA certificate and the certificate revocation list (CRL) to Active Directory.

For more information, compare Enterprise certification authorities. For general information about CAs, see Certification authorities.


Qualified subordination

Qualified subordination is an extension of standard certification authority (CA) subordination that allows you to:

  • Define the namespaces for which a subordinate CA will issue certificates.
  • Specify the acceptable uses of certificates issued by a qualified subordinate CA.
  • Create trust between separate certification hierarchies.

For more information, see Qualified subordination overview.

Qualified subordination properties

Qualified subordination properties are defined in the CA certificate request for a subordinate CA. The CA certificate that is used to install a qualified subordinate CA contains extensions where the different qualified subordination properties are listed. The following table describes the extensions in the CA certificate that are used to install a qualified subordinate CA:

Extension | Description
Name Constraints | The range of namespaces that are permitted or excluded by the qualified subordinate CA and its subordinates.
Policies | The list of acceptable policies for a certificate, included in the certificates issued by the qualified subordinate CA. These policies are identified in a certificate by object identifiers (also known as OIDs) and include both issuance and application policies. The object identifiers that are used are enterprise-dependent (or dependent within the scope of the object identifiers you use). The object identifier for an application in one PKI deployment must be different from another.
Policy Mapping | Determines how a policy object identifier from one trust hierarchy is mapped to a policy object identifier of another trust hierarchy.
Policy Constraints | Defines the certification path length required and allowed for policy identifiers and policy mapping.

All features of qualified subordinate CAs are new to the Windows Server 2003 family and are not available on Windows 2000 Server. To use these new features, you must use a Windows Server 2003 certification authority.

Note

  • The constraints and policy types listed above are defined in RFC 2459. For more information on RFCs, see the RFC Editor Web site.

Intranet and extranet qualified subordination

Qualified subordination may be used in both intranet and extranet environments. Intranet-qualified subordination involves a parent CA issuing a CA certificate to a qualified subordinate CA within a company's intranet. For example, you might install a qualified subordinate CA to issue certificates for a specific network domain in your network. Extranet qualified subordination establishes trust between CAs in separate networks.

Extranet qualified subordination is also commonly called cross-certification because trust is being established across separate certification hierarchies. For Windows Server 2003 certification authorities, cross-certification is synonymous with qualified subordination.

Name constraints

Name constraints specify a range of permitted and excluded namespaces that a qualified subordinate CA and its subordinates will use when evaluating certificate requests. A user requesting a certificate from a qualified subordinate CA is identifiable by one or more of the namespaces required by the certificate template for which the request is made. Name constraints are defined using the namespaces used in your network, such as DNS domain names. By permitting or excluding a namespace, the qualified subordinate CA permits or exclude all subjects that are identifiable by that namespace from receiving one of its certificates.

Name constraints apply to subtrees of a namespace. A permitted name constraint defines the namespace within which the CA may issue certificates. An excluded name constraint is used to exclude a subspace of a permitted namespace. For example, a CA with the permitted name constraint example.microsoft.com may have an excluded name constraint of TestDomain.example.microsoft.com. In this case, the CA and its subordinates will issue certificates for users within the example.microsoft.com namespace but not for users within the TestDomain.example.microsoft.com namespace.

Name constraint definition and usage

When the CA certificate for the qualified subordinate CA is created, name constraints are defined to determine what namespaces the qualified subordinate CA will permit or exclude. When the installed qualified subordinate CA receives a certificate request from an entity such as a user, name constraints determine whether the qualified subordinate CA will issue the certificate.

When someone submits a certificate request for a qualified subordinate CA to the parent CA, the parent CA uses the certificate path to verify that the qualified subordinate CA will not permit names that are excluded by any other CA in the certification path. If the name constraints defined in the CA certificate request permit names that a CA in the certification path excludes, then the certificate request is denied. If the permitted namespaces defined in the CA certificate request do not conflict with the permitted namespaces of the CAs in the certification path, then the CA certificate request is successful.

For a certificate request that is submitted to a qualified subordinate CA to be successful, all namespaces identified with the user in the certificate request must be within permitted namespaces and none may be within an excluded namespace.

The following name forms are allowed as name constraints. The RFCs listed may be found at the RFC Editor Web site.

Name form | Resource
Directory name (for example, Active Directory distinguished name) | Object names
DNS | RFC 1024
E-mail | RFC 822
URI/URL | RFC 1738
User principal name (UPN) | For more information, see Understanding Active Directory naming.
IP address | IPv4 RFC 791; IPv6 RFC 1883

Policies

Certificate policies describe the policies according to which a certificate was issued and define how it may be used. There are two types of policies used in qualified subordination:

  • Issuance policies
  • Application policies

Both policy types can be included in all types of certificates, including CA certificates and user certificates. This availability is in contrast to name constraints, policy mapping, and policy constraints, which are only used in creating the CA certificate for a qualified subordinate CA.

The policies that are available to a certificate template are first defined in the CA certificate for the qualified subordinate CA that will use certificate templates. Each policy listed has a corresponding object identifier (also known as an OID) identifying the policy. The object identifiers used are restricted to that policy for the entire public key infrastructure (PKI). The object identifiers assigned to policies in one PKI may be mapped to the policies in a separate PKI to facilitate trust. For more information, see Policy Mapping.

The issuance and application policies that are placed on a qualified subordinate CA must be within the set of policies object identifiers defined for all the CAs in the certification path of the qualified subordinate CA. When a qualified CA certificate request is evaluated, the policy object identifiers contained in the request are evaluated against the policy object identifiers used in the entire certification path to determine that the policy object identifiers contained in the request are a subset of the object identifiers used in the path. For a qualified subordinate CA to use issuance policies, policies must be present at every CA in the certificate hierarchy between the root CA and itself. For this reason, policy cannot be removed from a certification hierarchy, but can only be constrained when installing a qualified subordinate CA.

Issuance policies

The issuance policies that are contained in a certificate identify the assurance level of the certificate's subject when that subject presents the certificate to another entity. Assurance describes the extent to which a CA trusts a subject's identification; for example, whether the user is recognized by domain authentication only or if the user has passed multiple authentication stages. Assurance levels are defined for a PKI and issuance policies are used to represent them in certificates.

When a subject uses a certificate that contains an issuance policy, security entities can identify the assurance level of that subject and react accordingly. The security credentials that these assurance levels represent depend on how the policies are defined in the PKI.

For more information, see Issuance policies.

Application policies

Application policies are included in a certificate because they are required by the applications that will receive these certificates. Some applications have policy requirements and maintain a list of the policies that they will accept. When an application receives signed information, it compares the application policy object identifiers in the received certificate to its list or required policies. For example, a remote access server may require that a Client Authentication application policy be present in a certificate that is presented by a client performing a remote logon.

Application policies are similar to the Extended Key Usage extension in a certificate, as both use one or more object identifiers to prescribe how the public key in a certificate must be used. Extended Key Usage is still supported by Windows Server 2003 CAs to provide for PKIs that use this extension, but application policies replace them.

For more information, see Application policies.

Policy mapping

Policy mapping allows you to map a certificate policy object identifier in one trust hierarchy to a policy object identifier used in another trust hierarchy in your intranet or extranet. The policy mappings are defined in the CA certificate request for a qualified subordinate CA. Each pair of policies that is configured on the qualified subordinate CA indicates that it considers its trust hierarchy's policies equivalent to those in the other trust hierarchy.

For an example of policy mapping, see Policy mapping scenario.

When mapping the policies used in an external trust hierarchy, the qualified subordinate CA that contains the policy mappings is said to subordinate the CA in the external trust hierarchy whose policies it has mapped. This subordination does not require the administrator of the external trust hierarchy's CA to perform any task. This allows you to set up a trust relationship with another trust hierarchy by subordinating a single subordinate CA or the root CA of the external PKI.

For more information, see Policy Mapping.

Policy constraints

Policy constraints restrict certificate validation in two ways:

  • They require that each CA certificate in a certification path contain a specific policy.
  • They specify the number of CA certificates that are permitted in a certification path before policy mapping is no longer allowed.

Policy constraints are applied to both issuance and application policies. For more information, see Policy constraints.

Unexpected trust

When mapping policies between trust hierarchies in two different companies, there could be a problem of unexpected trust if a third company maps its policy object identifier to the mapped policies of one of the two companies. In this case, the third company is trusted by both of the other companies, which may not be wanted. In addition, either of the companies could make modifications to their certification hierarchies that would have the same effect. Policy constraints resolve this unexpected trust by restricting the certification path depth in which policy mapping may be used.

For more information, see Mapping policies between trust hierarchies; Policy constraints

Notes

  • XOX
  • Qualified subordination is performed by the parent CA on any subordinate CA and can therefore by applied to any type of CA, such as Windows NT 4.0, Windows 2000 Server, or other CAs.
  • Qualified subordinate CA certificate renewal is the same as standard subordinate CA renewal.
  • When qualified subordinate CA certificates and cross-certificates are revoked, they should also be deleted from the Active Directory directory service. This deletion is not required for security reasons, but is considered a best practice, because it also removes the certificates from the Local Machine certificates store of client computers.


Using Certificate Services

This section covers:

  • Installing and configuring a certification authority
  • Configuring the policy and exit modules
  • Establishing a certification hierarchy
  • Backing up and restoring a certification authority
  • Revoking certificates and publishing CRLs
  • Mapping certificates to user accounts
  • Renewing a certification authority
  • Managing Certificate Services from a command prompt
  • Certificate Services example implementations
  • Using qualified subordination


Installing and configuring a certification authority

This section will give you additional information you need to install and configure a certification authority (CA).

Planning the installation of a certification authority

Before installing Certificate Services, you should plan the deployment of certification authorities (CAs) and public key infrastructure in your organization.

For more information about deploying a PKI, see Resources in public key infrastructure and Windows Deployment and Resource Kits.

Ways to install Certificate Services to create a certification authority

If you are installing Certificate Services, there are a number of situations in which you may want to set up a CA. (The most typical is listed first here.)

  • After base setup has completed:

    To install Certificate Services on a server that already has XOX; XOX; or XOX installed, open Add or Remove Programs in Control Panel. (XOX) After you select Certificate Services for installation, the Certificate Services Installation Wizard guides you through the installation process.

    For the procedures to set up a certification authority (CA) as part of the base setup, see Set up a certification authority.

  • As part of Windows Server 2003 family base setup:

    Although Certificate Services is a service and is included with the Windows Server 2003 family, it is not installed as part of the initial installation process by default. (You do not want every file server to be a CA.)

    To install Certificate Services during the initial base installation of the Windows Server 2003 family, you must select it from the optional components list that is displayed during setup. Certificate Services will not actually be installed until you log on to the server after setup has completed. Then, a message will prompt you to complete the setup of the CA.

    XOX

Setup options and information

When you set up Certificate Services, you will be prompted for the following information:

Certification authority type selection

During the Certificate Services installation, you can choose to set up any of the following types of certification authority (CA):

Certification Authority Type | Description
Enterprise root CA | An enterprise root CA is a top-level CA in a certification hierarchy. An enterprise root CA requires the Active Directory directory service. It self-signs its own CA certificate and uses Group Policy to publish that certificate to the Trusted Root Certification Authorities store of all servers and workstations in the domain. Normally, an enterprise root CA does not directly provide resources for user and computer certificates, but is the foundation for a certificate hierarchy. For more information, see Enterprise certification authorities
Enterprise subordinate CA | An enterprise subordinate CA must obtain its CA certificate from another CA. An enterprise subordinate CA requires Active Directory. You use enterprise subordinate CAs when you want to take advantage of Active Directory, certificate templates, and smart card logon to XOX and computers running Windows Server 2003 family operating systems
Stand-alone root CA | A stand-alone root CA is a top-level CA in a certification hierarchy. The stand-alone root CA may or may not be a member of a domain and, therefore, does not require Active Directory. However, it will use Active Directory if it exists for publishing certificates and certificate revocation lists. Since a stand-alone root CA does not require Active Directory, it can easily be disconnected from the network and placed in a secure area, which is useful when creating a secure offline root CA. For more information, see Stand-alone certification authorities
Stand-alone subordinate CA | A stand-alone subordinate CA must obtain its CA certificate from another CA. The stand-alone subordinate CA may or may not be a member of a domain and, therefore, does not require Active Directory. However, it will use Active Directory if it exists for publishing certificates and certificate revocation lists. It must obtain its CA certificate from another CA.

Note

  • Certificate Services should not be installed on any node in a server cluster as this configuration may not allow Certificate Services to run properly and is therefore not supported.

Installing Web enrollment support

You may want to install a certification authority infrastructure within a defined security boundary and only allow specific computers to communicate with your certification authority. This means clients cannot connect directly to a CA to request and retrieve certificates. Or you may want to set up a CA that supplies certificates to Internet-based subjects. You may want to place a layer of insulation between these clients and the CA. Web enrollment allows these scenarios to be implemented easily.

Web enrollment is the component of a Microsoft CA that allows clients to submit certificate issuance and retrieval requests based on Web pages. It is installed when you install a Microsoft CA. It can also be installed on a non-CA computer to provide a Web front-end to your CA infrastructure on the back-end. In this configuration, clients make requests with the Web pages and only the computer that has Web enrollment installed needs to communicate with your CA.

For more information on installing Web enrollment, see Set up certification authority Web enrollment support.

Public and private key pair: cryptographic service providers, key lengths, hash algorithms

If you select the Use custom settings to generate the key pair and CA certificate check box when you choose the type of CA to install, you can select the cryptographic service provider (CSP) to use. The CSP generates the public key and private key pair and performs cryptographic operations on behalf of the CA.

You can set the key length for the public key cryptographic keys that the CA uses to sign certificates. In general, the longer the key length, the more secure it is. Note that a longer key will take more time to generate during setup and longer to transmit on the network when building certificate trust lists.

You can also choose the message hash algorithm used by the CA, as well as specifying the use of existing cryptographic keys instead of generating new ones.

Note

  • A CA may be installed using a smart card CSP. Once a CA is installed using a smart card CSP, the smart card must be available and inserted with the personal identification number (PIN) in order for the CA to start and perform its operations. This is a higher security option for CA operations than other options, but a disadvantage of using smart card CSPs is that CA performance may be slower and key length may be smaller.

    For more information about smart card CSPs, see "Certificate Services and Public Key Infrastructure" at the Microsoft Windows Resource Kits Web site (http://www.microsoft.com/)

Certification authority identifying information

The following are some guidelines for completing the CA identifying information in Certificate Services setup:

Field | Description
CA Name

The name you want to give to the CA. You can enter a string using any Unicode character. The name of the CA will also be the common name of the CA's distinguished name in Active Directory.

When special characters exist in the CA name, a sanitized CA name is used for operations that are unable to use the unmodified CA name. A CA's sanitized name is the name of the CA with all special characters encoded in a form that will allow them to be used for file names, CryptoAPI key container names, and Active Directory object names. Special characters are those characters that cannot be used in one or more of these names; the list includes all characters which are not ASCII characters and many ASCII punctuation characters.

Further, Active Directory object names are limited to 64 characters by the Lightweight Directory Access Protocol (LDAP) standard. To accommodate this limit, Active Directory object names are constructed by truncating the sanitized name and appending a hash computed over the truncated part of the sanitized name. The distinguished name suffix field is automatically filled with the distinguished name of the Active Directory domain. If you edit this distinguished name, you must conform with the LDAP standard.

Type certutil.exe at a command prompt without arguments to see the sanitized name for all of the published CAs. Type certutil.exe -v -ds to see all of the CA-related Active Directory names. The first column is a truncated CA name with the hash appended (the actual Active Directory object's container name, with special characters reverted back to their original form). A second column is displayed only if the truncated, sanitized name does not match the truncated CA name, and it is the actual Active Directory object's container name.
Distinguished name suffix | The X.500 distinguished name suffix that will be appended to the CA name.
Validity period | The length of time the CA's certificate should be valid. The CA will obtain a certificate that is valid for this length of time and use that certificate's private key for signing issued certificates and certificate revocation lists.

Database and configuration storage

Certificate Services uses local storage for its database, configuration data, backup data and logging data. You can specify locations for the database and log during CA setup. By default, the certificates issued by a CA are stored in:

\Systemroot\system32\certlog

For best performance, the database and log files should be kept on separate physical disk drives, preferably on separate disk controllers. This will maximize disk throughput and allow the CA to perform better.

You also have the option of specifying a shared folder when setting up a CA. The shared folder acts as a location where computer users can find information about certification authorities. This option is only useful if you are installing a stand-alone CA and do not use Active Directory.

If the host computer for Certificate Services is a member of a domain, information about the CA is automatically published to the Active Directory. However, the Active Directory does not act as the database for Certificate Services. This function remains with the local computer.

Note

  • It is considered unsafe to install Certificate Services on an FAT file system because FAT does not support domain-based security. Always install Certificate Services on a NTFS file system to take advantage of support for a variety of features including Active Directory, which is needed for domains, user accounts, and other important security features.

(Optional) Creating an issuer policy statement for the CA

When you set up a CA, you can add a CA policy statement to the CA certificate that is created during setup or a CA certificate renewal, in the form of text or a pointer to a Web site. The CA policy statement gives legal and other pertinent information about the CA and its issuing policies, limitations of liability, and so on. An end user will see this CA policy statement when they view the CA certificate and click Issuer Statement.

Here are the steps you need to follow to attach a policy statement to a CA's certificate:

  • The policy statement file must be installed before you set up Certificate Services. This file, named CAPolicy.inf, must be placed in the systemroot directory. URLs in CAPolicy.inf should use the replaceable parameter syntax that also appears in the Extensions tab. If you don't use the replaceable parameter syntax, then CDP and AIA extensions in renewed CA root certificates may point to the same location that was specified in the previous CA root certificate. To see the syntax for replaceable parameters, see Specify certificate revocation list distribution points in issued certificates.

  • The first two lines of CAPolicy.inf must be:

    [Version]
    Signature="$Windows NT$"

  • The next two lines of the file list the name of the policies for this CA. Multiple policies can be listed in Policies= if they are separated by commas. The name LegalPolicy is used here as an example, but the name can be whatever the CA administrator chooses when creating CAPolicy.inf:

    [CAPolicy]
    Policies=LegalPolicy

  • For each policy, you need to provide a user-defined object identifier (also known as an OID) and either the text you want displayed as the policy statement or a URL pointer to the policy statement. (The URL can be in the form of an HTTP, FTP, file, or LDAP address.) Continuing on with the example, if you are going to have text in the policy statement, the next three lines of CAPolicy.inf will read:

    [LegalPolicy]
    OID=1.1.1.1.1.1.1.1.1
    Notice="Legal policy statement text"

    If you are going use a URL to host the CA policy statement, the next three lines would instead read:

    [LegalPolicy]
    OID=1.1.1.1.1.1.1.1.1
    URL="http://CompanyWebSite/CAPolicy/default.asp"

    (Please note that the "OID=" entry used in this example is arbitrary and is shown only for illustrative purposes.)

    In addition:

    • Multiple URLs are supported
    • Multiple notices are supported
    • Mixed notices and URLs are supported
    • URLs with spaces or text with spaces must be surrounded by quotes

    An example of multiple notices and URLs in a policy section might be:

    [LegalPolicy]
    OID=1.1.1.1.1.1.1.1.1
    URL = "http://http.microsoft.com/somewhere/default.asp"
    URL = "ftp://ftp.microsoft.com/somewhere else/default.asp"
    Notice = "Legal policy statement text."

  • You can specify CRL Distribution Points (CDPs) in CAPolicy.inf. Note that any CDP in CAPolicy.inf will take precedence for certificate verifiers over the CDP's specified in the CA policy module. If you want to specify the CDP using CAPolicy.inf, a sample of the syntax is:

    [CRLDistributionPoint]
    URL="http://CompanyWebSite/Public/myCA.crl"

    Some additional notes about the CRL section:

    • Multiple URLs are supported.
    • HTTP, file, FTP, and LDAP URLs are supported.
    • This section can be used during CA setup or CA certificate renewal.
    • This section is only used if you are setting up a root CA or renewing a root CA certificate. Subordinate CA CRL distribution point extensions are determined by the CA which issued the subordinate CA's certificate.
    • URLs with spaces must be surrounded by quotes.

    • If no URLs are specified (in other words, if the [CRLDistributionPoint] section is empty), the default CRL Distribution Point extension will be suppressed.

  • You can specify the authority information access points in CAPolicy.inf. The syntax is:

    [AuthorityInformationAccess]
    URL="http://CompanyWebSite/Public/myCA.crl"

    Some additional notes about the authority information access section:

    • Multiple URLs are supported.
    • HTTP, file, FTP, and LDAP URLs are supported.
    • This section can be used during CA setup or CA certificate renewal.
    • This section is only used if you are setting up a root CA or renewing a root CA certificate. Subordinate CA authority information access extensions are determined by the CA which issued the subordinate CA's certificate.

    • If no URLs are specified (in other words, if the [AuthorityInformationAccess] section is empty), the default Authority Information Access extension will be suppressed.

  • Another optional section of CApolicy.inf is [EnhancedKeyUsage], which is used to specify Enhanced Key Usage extension object identifiers (also known as OIDs).

    • Multiple object identifiers are supported.
    • This section can be used during CA setup or CA certificate renewal.
    • This section is only used if you are setting up a root CA or renewing a root CA certificate. The Enhanced Key Usage extension for a subordinate CA is determined by the CA which issued the subordinate CA's certificate.

    An example of this section is:

    [EnhancedKeyUsage]
    OID=1.2.3.4.5
    OID=1.2.3.4.6

  • Another optional section of CApolicy.inf is [certsrv_server], which is used to specify renewal key length, the renewal validity period, and the certificate revocation list (CRL) validity period for a CA that is being renewed or installed.

    An example would be:

    [certsrv_server]
    RenewalKeyLength=2048
    RenewalValidityPeriod=Years
    RenewalValidityPeriodUnits=5
    CRLPeriod=Days
    CRLPeriodUnits=2
    CRLDeltaPeriod=Hours
    CRLDeltaPeriodUnits=4

    • RenewalKeyLength sets key size for renewal only. This is only used when CA renewal is generating new keys.
    • RenewalValidityPeriod and RenewalValidityPeriodUnits establish the lifetime of new root CA certificate when renewing the old CA certificate.
    • CRLPeriod and CRLPeriodUnits establish the validity period for the full CRL, while CRLDeltaPeriod and CRLDeltaPeriodUnits establish the validity period for the delta CRL.
    • RenewalKeyLength, RenewalValidityPeriod and RenewalValidityPeriodUnits are only processed when the CA is being renewed.
    • LoadDefaultTemplates is not processed when the CA is a subordinate CA.


Configuring the policy and exit modules

The administrator of a certification authority (CA) can configure settings in the default policy and exit modules provided with Certificate Services by using the Certification Authority snap-in.

Policy module setting you can change:

    The default action of the certification authority upon receiving a valid certificate request. You can specify whether a stand-alone CA will hold incoming certificate requests as Pending or automatically issue the certificate. In most cases, for security reasons, it is recommended that all incoming certificate requests to a stand-alone CA be marked as Pending.

    For the procedure to change the default action of a certification authority upon receipt of a certificate request, see Set the default action upon receipt of a certificate request.

Exit module settings you can change:

    Allow certificate publication to the file system. You can select whether to allow the publishing of certificates to the file system. Actual publication will only occur if the certificate request specifies a file system location where the certificate is to be published.

    For the procedure to allow or disallow the publishing of certificates to the file system, see Publish certificates to the file system.

    Sends e-mail when a certification event occurs. You can configure the CA to send e-mail when a certification event occurs, such as the issuance of a certificate or when a certificate request is set to pending.

    To configure e-mail sending options, see Send e-mail when a certification event occurs.

For more information about policy and exit modules, see Policy and exit modules.

If you want to replace the policy module provided with Certificate Services with a custom policy module or a policy module developed for Certificate Server 1.0 and Windows NT 4.0, you must first register the policy module .dll file by typing rgsrv32 yourmodule.dll at a command prompt and then follow the procedure in Select a different policy module.


Establishing a certification hierarchy

The first step to establish a certification hierarchy is that a Domain Admin installs a root certification authority (CA).

Using a Microsoft certification authority as your root authority

The installation process for a Certificate Services root authority generates a root CA certificate containing the CA's public key and the digital signature created using the root's private key. If the root authority is installed using Certificate Services on a server that has access to the Active Directory directory service, the root authority's certificate will automatically be placed in all users' Trusted Root Certification Authorities certificate store, thereby establishing forest-wide trust in the root CA.

Using a certification authority outside of your organization as your root authority

If your organization is using a non-Microsoft certification authority from outside your organization as the root authority, you will need to obtain the root certificate and distribute it to any user and computer that needs to establish trust in the root authority. One way to distribute this type of root certificate to XOX and Windows Server 2003 family users is to use a certificate trust list (CTL) by way of Group Policy. For more information about distributing third party root certificates using Group Policy, see Enterprise trust policy.

Using a non-Microsoft certification authority inside your organization as your root authority

If your organization is using its own non-Microsoft certification authority (CA) as the root authority, you will need to obtain the root certificate and distribute it to any user and computer that needs to establish trust in the CA root authority. One way to distribute a root certificate to XOX and Windows Server 2003 family users is to use the Trusted Root Certification Authorities policy setting via Group Policy. For more information about distributing non-Microsoft root certificates using Group Policy, see Policies to establish trust of root certification authorities.

Subordinate certification authorities

After trust in a root authority has been established, you can install certification authorities (CAs) that are subordinate to the root CA as well as installing subordinate CAs that are subordinate to other subordinate CAs. By doing this, you can create a chain of parent-child relationships between CAs that serve different functions in an organization's public key infrastructure (PKI). The only significant difference in the installation process between a root CA and a subordinate CA is that a certificate request is generated for submission to another CA by a subordinate CA instead of creating a self-signed certificate. This request may be routed automatically to online CAs located via Active Directory, or routed manually, if offline. In either case, the resulting certificate must be installed on the new subordinate CA before it can begin operation.

Note that there is a relationship between the enterprise CAs and the Windows Server 2003 family domain trust model, but this does not imply a direct mapping between CA trust relationships and domain trust relationships. There is nothing that prevents a single CA from servicing entities in multiple domains or even entities outside the domain boundary. Similarly, a given domain may have multiple enterprise and root CAs.

For a brief overview of certification hierarchies, see Certification authority hierarchies.

For extensive information about planning certification hierarchies, refer to the Windows Deployment and Resource Kits.


Backing up and restoring a certification authority

The purpose of backup and restore operations is to protect the certification authority (CA) and its operational data from accidental loss due to hardware or storage media failure. The recommended method to back up a CA is to use Backup (included with the operating system) to back up the entire server, including the system state which contains the CA's data.

It is also possible to back up and restore a CA using the Certification Authority snap-in, but this backup method is intended for use only in special cases where you do not want to back up the entire server on which the CA is installed. Using the Certification Authority snap-in, you can back up and restore the following types of information:

  • Private key, and the certificate that the CA uses for digitally signing
  • Certificate database

The public key and private key are backed up or restored using the PKCS #12 PFX format.

The Backup or Restore Wizard will ask you to supply a password when backing up the public and private keys and CA certificate. This password will be needed to restore the CA. For procedures on backing up a CA using the Certification Authority snap-in, see Back up a certification authority.

After performing the initial full backup of the CA, you can do incremental backups from that point on. When restoring, you will need to restore the full backup first and then each incremental backup in the order that they were created. For procedures on restoring a CA using the Certification Authority snap-in, see Restore a certification authority from a backup copy.

Important

  • In general, you should use Backup to back up and restore both the CA and the server. For more information about backing up a Windows Server 2003 family computer, see Backing up and restoring data.

Upon restoring a CA, the Internet Information Services (IIS) metabase must also be restored if it has been damaged or lost. If a damaged or missing IIS metabase is not restored, IIS will fail to start, and that will result in Certificate Services Web pages failing to load. The IIS snap-in is used to back up the IIS metabase. Backup should be used to back up the IIS Web content pages and the CA. An alternative method is to recreate the IIS metabase and then use the certutil.exe -vroot command at a command line to reconfigure the IIS server to support the CA Web pages.

When restoring a CA, if the database logs are not manually deleted before the restore, the CA will be restored to the point in time of the restore—the database logs will be replayed, and changes made since the last backup will be applied to the database. (The default location of the database logs is systemroot\system32\certlog). If the database logs are manually deleted before the restore, the CA will be restored to the point in time that the backup was performed.

For more information on backup, restore, and verification of a CA backup, see Certutil tasks for backing up and restoring.


Revoking certificates and publishing CRLs

You can use the Certification Authority snap-in to revoke a certificate, to administer certificate revocation list (CRL) publication, and to specify the CRL Distribution Points (CDPs) published in every certificate issued by the certification authority (CA).

Revoking a certificate

To help maintain the integrity of an organization's public key infrastructure (PKI), the administrator of a CA must revoke a certificate if the subject of certificate leaves the organization, if the certificate subject's private key has been compromised, or if some other security-related event dictates that it is no longer desirable to have a certificate considered "valid." When a certificate is revoked by a CA, it is added to that CA's certificate revocation list (CRL). This may take the form of a new CRL or a delta CRL, which is a small CRL that lists the certificates that have been revoked since the last full CRL.

For conceptual information about the role of certificate revocation and revocation checking in a PKI, see Certificate revocation. For the procedure to revoke a certificate, see Revoke an issued certificate. For instructions on how to display the current CRL, see View the certificate revocation list.

Scheduling certificate revocation list (CRL) publication

One of the features of Certificate Services is that every CA automatically publishes an updated CRL after an interval of time specified by the administrator of the CA. This interval of time is known as the CRL "publish period." After the initial setup of a CA, the CRL publish period is set to one week (based upon the local computer's time, starting from the date when the CA is first installed). For the procedure to change a certification authority's CRL publishing interval, see Schedule the publication of the certificate revocation list. The CRL and delta CRL publish periods can be scheduled independently.

A CA administrator should understand that there is a difference between a CRL publish period and the validity period of a CRL. The validity period of a CRL is the period of time that the CRL is considered authoritative by a verifier of a certificate. As long as the verifier of a certificate has a valid CRL in its local cache, it will not attempt to retrieve another CRL from the CA which publishes it.

The publish period of a CRL is established by the CA administrator. However, the validity period of the CRL is extended from the publish period to allow for Active Directory replication. By default, Certificate Services extends the publish period by 10% (up to a maximum of 12 hrs) to establish the validity period. So, for example, if a CA is publishing a CRL every 24 hours, the validity period is set to 26.4 hours.

Additionally, there is a clock skew of an additional 10 minutes added to the validity period on either side of the publish period, so a CRL will be valid 10 minutes before the beginning of its publish period to account for variances in computer clock settings.

There are registry entries which allow an administrator to control the variance between publish period and validity period to allow for slower directory replication. For information about these registry entries, see the Windows Deployment and Resource Kits.

When determining the schedule for CRL publishing, there is a trade-off between performance and security. The more often CRLs are published, the more current clients can be with the list of revoked CRLs and the less likely they are to accept recently-revoked certificates. However, frequent publishing can negatively impact network and client performance. To help mitigate this trade off, delta CRLs can be used if the environment supports them.

Using delta certificate revocation lists

CRLs can become very long on large CAs that have experienced significant amounts of certificate revocation. This can become a burden for clients to download frequently. To help minimize frequent downloads of lengthy CRLs, delta CRLs can be published. This allows the client to download the most current delta CRL and combine that with the most current base CRL to have a complete list of revoked certificates. Because the client will normally have the CRL cached locally, the use of delta CRLs can potentially improve performance.

To use delta CRLs, the client application must be aware of and explicitly use delta CRLs for revocation checking. If the client does not use delta CRLs, it will retrieve the CRL from the CA every time it refreshes its cache, regardless of whether a delta CRL exists or not. For this reason, you should verify that the intended applications use delta CRLs and configure the CA accordingly. If the clients do not support the use of delta CRLs, you should either not configure the CA to publish delta CRLs or configure it so CRLs and delta CRLs are published at the same interval. This would still allow future applications that support delta CRLs to use them, while providing current CRLs to all applications. Note that all applications that use CryptoAPI in XOX and the Windows Server 2003 family use delta CRLs.

Publishing a CRL before the next scheduled publish period

You can also publish a CRL on demand at any time, such as when a valuable certificate becomes compromised. Choosing to publish a CRL outside the established schedule resets the scheduled publication period to begin at that time. In other words, if you manually publish a CRL in the middle of a scheduled publish period, the CRL publish period is restarted.

It is important to realize that clients that have a cached copy of the previously published CRL will continue using it until its validity period has expired, even though a new CRL has been published. Manually publishing a CRL does not affect cached copies of CRLs that are still valid; it only makes a new CRL available for systems that do not have a cached copy of a valid CRL.

For the procedure to force the immediate publication of a CRL or delta CRL, see Manually publish the certificate revocation list.

CRL distribution points and the CRL file name

Every certificate that is issued by a Microsoft certification authority has CRL distribution points as part of its content. A CRL distribution point provides a certificate verifier with the network location where it can retrieve the current copy of the CRL or delta CRL. For procedures to designate the certificate revocation list distribution points in certificates, see Specify certificate revocation list distribution points in issued certificates.

By default, CRL and delta CRL files are published on the CA in the following location:

Systemroot\System32\Certsrv\Certenroll

The format of the CRL file name is the "sanitized name" of the CA plus, in parentheses, the "key id" of the CA (if the CA certificate has been renewed with a new key) and a .crl extension. Refer to the table for some sample CRL file names based on sample renewal histories of a CA:

Scenario | Name of CRL file
A certification authority named "MyCA" that has never had its CA certificate renewed | myca.crl
A certification authority named "MyCA" that has been renewed once with the same key | myca.crl
A delta CRL for a certification authority named "MyCA" that has been renewed once with the same key | myca+.crl
A certification authority named "MyCA" that has been renewed once with a new key | myca(1).crl
A certification authority named "MyCA" that has been renewed twice with a new key | myca(2).crl

See Installing and configuring a certification authority for information about a CA's "sanitized name."

See Renewing a certification authority for more information about CA renewal.

Enabling Netscape-compatible Web-based revocation checking

To enable Netscape-compatible Web-based revocation check extensions to be added to every certificate, run the following certutil command from the command prompt on the certification authority:

certutil -SetReg Policy\RevocationType +AspEnable

Then, stop and start the Certification Authority service. Certificates issued by the certification authority after it is restarted will contain the extension.

Important

  • Because clients that use this type of revocation checking will access the CA through Web pages, Internet Information Services must have access to read the revocation information from the CA. If IIS does not have at least read-only access to the CA, access is denied by the CA and the revocation information will not be available.

For more information on the certutil command, see CertUtil.


Mapping certificates to user accounts

It is possible to map (or create an association from) a certificate that has been issued to a user to the user's account. A server application can then use public key cryptography technology to authenticate the user using this certificate. If the user is authenticated, then the user's account is logged on. The end result is the same as if the user provided a user ID and password, yet the process is much more manageable.

Traditionally, computer systems have used a centralized accounts database to manage users, their user rights, and their access controls. This technique has worked well and is well understood. However, as systems become more and more distributed—with hundreds of thousands to millions of users—this form of centralized control becomes unwieldy. The problems range from trying to verify an account against a database located on the other side of the Internet to administering a lengthy list of users.

Public key certificates can help simplify these problems. Certificates can be widely distributed, issued by numerous parties, and can be verified by simply examining the certificate, without having to refer to a centralized database. However, existing operating systems and administration tools can only deal with accounts, not certificates. The simple solution—one that maintains the advantages of both certificates and user accounts— is to create a mapping between a certificate and a user account. This allows the operating system to continue using accounts while the larger "system" and the user use certificates.

In this model, when a user presents a certificate, the system looks at the mapping to determine which user account should be logged on. (Note that this should not be confused with logging on with a smart card. XOX; XOX; and XOX support logging on with a smart card using account mapping that is automatic.)

Types of mapping

In most cases, a certificate is mapped to a user account in one of two ways: a single certificate is mapped to a single user account (one-to-one mapping) or multiple certificates are mapped to one user account (many-to-one mapping).

User principal name mapping

User principal name mapping is a special case of one-to-one mapping. To use user principal name mapping, you must use the Active Directory directory service. With user principal name mapping, the user principal name is used to find the user's account in Active Directory and log it onto the network or host. The user principal name looks very much like an e-mail name, and is unique within a XOX; XOX; or XOX domain. Enterprise certification authorities (CAs) place the user principal name of the certificate holder into each certificate. Thus, for accessing a secure IIS server or logging on to XOX; XOX; or XOX with a smart card, the mapping of user names to accounts is automatic on these certificates.

For more information on using Active Directory for certificate mapping, see To map a certificate to a user account.

One-to-one mapping

One-to-one mapping maps a single user certificate to a single user account. For example, imagine you want to provide a Web page to your employees that will allow them to view and modify their deductions, manage their health care, and a number of other benefits options. This page should work over the Internet and should be secure. As a solution, you decide to use certificates and certificate mapping on XOX; XOX; or XOX. You can either issue certificates to each of your employees from your own certificate service, or you can have your employees get certificates from a certification authority approved by your company. You can then take these user certificates and map them to the employee's user account. This allows a user to connect to the Web page using SSL (Secure Sockets Layer) or TLS (Transport Layer Security) from anywhere by providing his or her client certificate. The user then logs onto his or her own user account and normal access controls can be applied.

Many-to-one

Many-to-one mapping maps many certificates to a single user account. For example, you have a partnership with an agency that provides temporary workers for your job openings. You would like to allow the agency personnel to view Web pages that describe current job openings that only company employees can see. The agency has its own certification authority that it uses to issue certificates to its employees. After installing the agency certification authority's root certificate as a trusted root in your enterprise, you can set a rule that maps all certificates issued by that certification authority to a single XOX; XOX; or XOX account. You can then set the access rights of the account so this account can access that Web page.


Renewing certification authorities

Why certification authorities need to be renewed

A certification authority may need to be renewed for either of the following reasons:
  • Change in the policy of certificates issued by the CA
  • Expiration of the CA's issuing certificate

Certification authority validity periods

Every certificate issued by a certification authority (CA) has a validity period. The validity period is the range of time where the certificate can be accepted as an authoritative credential of the identity of the subject of the certificate. This is, of course, assuming the certificate is not revoked before the validity period ends and that the issuing CA is trusted. The primary purpose of the validity period is to limit the time in which a certificate is exposed to the possibility of being compromised.

Since a CA is really just another entity that has been issued a certificate—either issued by itself (in the case of a root CA) or issued by a parent (in the case of a subordinate CA)—every CA has a built-in expiration date, as determined by the end of the validity period on its CA certificate. This is not meant to imply that the lifetime of a CA is equivalent to the validity period of its CA certificate, only that a CA can not issue certificates if it does not have a valid certificate of its own. The lifetime of a CA includes the validity periods of all its CA certificates—past and present. With these considerations in mind, an organization with a public key infrastructure (PKI) has to plan for the renewal of every certificate that is issued to a CA in the certification hierarchy in order to maintain the existing trust relationships in the PKI and to extend the lifetimes of CAs.

The validity period of a CA and the validity period of the certificates it issues

Before discussing the renewal of a CA certificate, it is helpful to understand how the end of the validity period of a CA affects the validity period of the certificates it issues. Certificate Services enforces a rule that a CA never issues a certificate to be valid beyond the expiration date of its own certificate. Therefore, when a CA's certificate reaches the end of its validity period, all certificates it has issued will also expire. This way, if the CA is purposely not renewed and the CA reaches the end of its lifetime, a PKI administrator can be assured that all the certificates that the now-expired CA has issued can no longer be used as valid security credentials. In other words, there will be no "orphaned" certificates that are still within their validity period but which have been issued by a CA that is no longer valid.

To illustrate how a decreasing validity period works, consider the following scenario: An organization installs a root CA with a certificate validity period of five years. The organization then uses this root CA to issue certificates with a validity period of two years to subordinate CAs. For the first three years every certificate issued to a subordinate CA by the root CA will continue to have a validity period of two years. After three years, when there is less than two years left in the validity period of the root CA certificate, Certificate Services begins to reduce the validity period of the certificates issued by the root CA so that they do not exceed the end of the CA's certificate's expiration date. Therefore, after four years, the CA issues subordinate CA certificates that are valid for one year. After 4.5 years, issued subordinate CA certificates have a validity period of only six months.

Certificate Services allows for the following maximum validity periods that are based on the type of certificate. These validity periods are configurable by the Domain Admin or Enterprise Admin when using version 2 certificate templates:

Type of certificate | Maximum validity period
Root CA | Specified during setup of Certificate Services
Subordinate CA, Internet Protocol Security, Enrollment Agent, Domain Controller | Up to 5 years, never more than the Root CA's validity period
All other certificates | 1 year, never more than the Root CA's validity period

Planning for the renewal of a CA

Since a CA that is approaching the end of its own validity period issues certificates valid for shorter and shorter periods of time, you need to have a plan in place to renew the CA well before it expires in order to avoid issuing certificates of a very short validity period.

One renewal consideration: When you renew a CA, you have the option of reusing its existing key pair or generating a new key pair. When you generate a new key pair for a CA that is being renewed, a new certificate revocation list (CRL) distribution point is also created. This is to ensure that the key used to sign a certificate issued by the CA also matches the key used to sign the CRL. For more information about how renewing a CA with a new key affects certificate revocation and the name of CRLs, see Revoking certificates and publishing CRLs.

The following strategies are presented as possible approaches an organization could take when planning for CA renewal. You may need to adapt these to your specific situation.

  • Renewing a root certification authority

    Since the root CA is the most critical CA in the hierarchy, you may prefer to have a strategy here that reduces the need to renew the root certificate often.

    The first consideration is choosing the key length of the root's public key and private key pair during setup of the root authority. By using a long key length, which is generally more secure against brute force attack by a hacker than a shorter key length, you increase the length of time that the CA can use the same private key and have reasonable confidence that it has not been compromised. The second consideration is establishing the validity period of the root certificate itself. In general, you will want to create a root certificate that has a shorter validity period than the estimated lifetime of the key.

    Keeping these considerations in mind, a possible strategy for setting up a root CA that reduces the need for frequent renewal would be to create a 4096-bit RSA key during Certificate Services setup. Given the current state of computer technology, one estimate is that a 4096-bit private key is reasonably secure from a brute force attack for 15-20 years. After creating the 4096-bit key in Certificate Services setup, you could create a root certificate using the 4096-bit key that is valid for five years. Afterwards, the CA's certificate should be renewed every four years (one year before the expiration of the validity period), each time with a certificate validity of five years. Of course, every time the CA certificate is renewed, the administrator will have to assess whether the same key, given current computer technology and other security considerations, can be used with confidence for the next five years.

  • Renewing a subordinate certification authority

    Intermediate CAs

    Within an organization's certification hierarchy, some subordinate CAs may be "intermediate" CAs . In other words, they do not issue certificates to end users or computers; they only issue certificates to other subordinate CAs that are below them in the certification hierarchy. For these intermediate CAs, given their limited role and the relative ease of monitoring their certificate database logs, a possible strategy may be to renew them a year to six months before they expire and reuse the existing key.

    Issuing CAs

    For subordinate CA's that do issue certificates to end users and computers, sometimes referred to "issuing" CAs, a preferable strategy may be to renew the CA's certificate regularly with a new key 6-12 months before the end of the CA's validity period, for example. This makes an attack by a hacker on any one key less valuable, since any compromised key would have a relatively limited lifetime.

    The other advantage of renewing an issuing CA using a new key is CRL management. When a CA is renewed with a new key, it begins to publish a separate CRL for the revoked certificates it has issued using the new key. It also will continue to publish a CRL for certificates signed with the old key, for as long as those revoked certificates validity period is still in effect. This is something a CA administrator may want to exploit if the CA is issuing a large number of certificates and, potentially, revoking a large number of those certificates. It may be advantageous to reduce the possibility of having one huge CRL that certificate verifiers have to download. Instead, issue a number of certificates with one key, renew the CA early into its validity period with a new key, then issue a number of certificates using the new key. In this way, you will reduce the size of the CRL that the certificate verifier has to download when presented with a certificate from an issuing CA.

For more detailed information about planning for renewal and renewing Microsoft certification authorities, refer to the Windows Deployment and Resource Kits.

Procedures to renew CAs

For the procedure to renew a root CA, see Renew a root certification authority.

For the procedure to renew a subordinate or intermediate CA, see Renew a subordinate certification authority.


Managing Certificate Services from a command prompt

There are two utilities you can use to manage certificates at a command prompt:

  • Certutil is a useful tool for administrators who are managing CAs and troubleshooting certificate-related issues.
  • Certreq requests certificates from a certification authority (CA).

For information about other command-line utilities, see Command-line reference. For more information about manageability, see Management Strategies and Tools.


Example implementations

Microsoft Windows Graphic

Certificate Services example implementations

This section covers:

  • Certificate Services example implementation: Establishing autoenrollment for user certificates
  • Certificate Services example implementation: Key archival and recovery


Certificate Services example implementation: Establishing autoenrollment for user certificates

These tasks are required for using key recovery on a Microsoft certification authority (CA):

  1. Duplicate the User template and use the copy for autoenrollment
  2. Configure an enterprise certification authority to issue the Autoenrolled User certificate
  3. Establish policy for autoenrollment of Domain Users

Prerequisites

Before doing these tasks, for the purposes of this walkthrough:

  • The Windows Server 2003 domain controller must also be configured as an enterprise subordinate or root CA. The CA is referred to by the name EntCA in this walkthrough.

Duplicate the User template and use the copy for autoenrollment

  1. Click Start, click Run, type mmc, and then click OK.
  2. On the File menu, click Add/Remove Snap-in, and then click Add.
  3. Under Snap-in, double-click Certificate Templates, click Close, and then click OK.
  4. In the console tree, click Certificate Templates. All of the certificate templates will be displayed in the details pane.
  5. In the details pane, click the User template.
  6. On the Action menu, click Duplicate Template.
  7. In the Display Name field, type Autoenrolled User.
  8. Make sure that the Publish Certificate in Active Directory check box is selected.
  9. Click the Security tab.
  10. In the Group or user names field, click Domain Users.
  11. In the Permissions for Domain Users list, select the Enroll and Autoenroll permission check boxes and then click OK.

    Autoenrolling Domain Users is an example. These permission settings are variable, depending on who you want to autoenroll for these certificates.

Configure an enterprise certification authority to issue the Autoenrolled User certificate

  1. Open Certification Authority.
  2. In the console tree, click Certificate Templates.

    Where?

    • Certification Authority
    • CA name
    • Certificate Templates
  3. On the Action menu, point to New, and then click Certificate to Issue.
  4. Click Autoenrolled User and click OK.

Note

  • XOX

Establish policy for autoenrollment of Domain Users

You must be using the Windows Server 2003 Active Directory schema for this procedure to work.

  1. Click Start, click Run, type mmc, and then click OK.
  2. On the File menu, click Add/Remove Snap-in, and then click Add.
  3. Under Snap-in, double-click Active Directory Users and Computers, click Close, and then click OK.
  4. In the console tree, click the domain name.

    Where?

    • Active Directory Users and Computers
    • Domain name
  5. On the Action menu, click Properties.
  6. Click the Group Policy tab and click Edit.
  7. In the console tree, click Public Key Policies under User Configuration.

    Where?

    • Default Domain Policy
    • User Configuration
    • Windows Settings
    • Security Settings
    • Public Key Policies
  8. In the details pane, double-click Autoenrollment Settings.
  9. Click Enroll certificates automatically.
  10. Select the Renew expired certificates, update pending certificates, and remove revoked certificates check box.
  11. Select the Update certificates that use certificate templates check box and click OK.
  12. Click File, click Exit, and then click OK.

Notes

  • XOX
  • Unless users refresh their security policy using the GPUpdate command, it will take a number of hours for the autoenrollment policy to take effect.
  • When autoenrollment retrieves a certificate that is configured to be stored on a smart card, you will receive a message when the certificate is ready to be stored on the smart card. If the message refers to a type of smart card that you do not have, click Cancel until the correct smart card type appears. You then provide the smart card PIN and the certificate will be stored on the smart card.
  • When autoenrollment enrolls for a certificate that requires user interaction for the enrollment process, you will receive a Certificate Enrollment message and an icon appears on your taskbar. Clicking that icon or message begins the certificate autoenrollment process.


Certificate Services example implementation: Key archival and recovery

Here are the tasks required for using key recovery with a Microsoft certification authority (CA):

  1. Create a key recovery agent account
  2. Acquire the key recovery agent certificate
  3. Configure the certification authority to allow key recovery
  4. Create a new certificate template that allows key archiving
  5. Acquire an user certificate that has an archived key
  6. Perform key recovery
  7. Import the recovered private key

Note

  • Steps 6 and 7 are not required to configure key archival. They are used when a private key is lost and key recovery must take place.

Prerequisites

Before doing these tasks, for the purposes of this walkthrough:

  • You must have a Windows Server 2003 domain controller. A fictitious domain, adventure-works.com, is used in this walkthrough.
  • The Windows Server 2003 domain controller must also be configured as an enterprise root or subordinate CA. The CA is referred to by the name EntCA in this walkthrough.

Task 1—Creating a Key Recovery Agent account

Configure and add the Key Recovery Agent certificate template as a template that can be issued by the enterprise CA.

Important

  • Perform the following procedures at the domain controller.

1. Verify who can enroll the Key Recovery Agent template

    a. Log on as Administrator@adventure-works.com.

    b. Click Start, click Run, type certtmpl.msc and then press Enter.

    c. In the console tree, click Certificate Templates.

    d. In the details pane, right-click Key Recovery Agent and click Properties.

    e. In Key Recovery Agent Properties, click the Security tab.

    By default, the security groups can enroll the Key Recovery Agent certificate template are Domain Administrators and Enterprise Administrators.

    f. If you want another recovery agent, click Add to add the user and grant that user Read and Enroll permissions.

2. Change the default issuance behavior of the Key Recovery Agent template

    a. In Key Recovery Agent Properties, click the Issuance Requirements tab.

    b. Clear the CA certificate manager approval check box and click OK.

    c. Close Certificate Templates.

3. Configure the EntCA certification authority to issue Key Recovery Agent certificates.

    a. On the Administrative Tools menu, click Certification Authority.

    b. In the console tree, double-click EntCA, and then click Certificate Templates.

    c. Right-click Certificate Templates, then click New, and then click Certificate to Issue.

    d. In Select Certificate Template, click Key Recovery Agent, and then click OK.

Task 2—Acquiring the Key Recovery Agent certificate

In this series of steps, you will acquire a Key Recovery Agent Certificate for the purpose of recovering private keys.

Important

  • Perform the following procedures at the domain controller.

1. Create an MMC console with the Certificates snap-in loaded.

    a. Ensure that you are logged on as administrator@adventure-works.com.

    b. On the taskbar, click the Start button, and then click Run.

    c. In Run, type mmc, and then click OK.

    d. On the File menu, click Add/Remove Snap-in.

    e. In Add/Remove Snap-in, click Add.

    f. In the Add Stand-alone Snap-in, click Certificates, and then click Add.

    g. In Certificates, click User account and then click Finish.

    h. Click Close, and then click OK.

2. Acquire a Key Recovery Agent certificate.

    a. In the newly-created MMC console, in the console tree, double-click Certificates (Current User).

    b. In the console tree, right-click Personal, click All Tasks, and then click Request New Certificate.

    c. In the Certificate Request Wizard, click Next.

    d. In Certificate Template, select Key Recovery Agent, and then click Next.

    e. In the Certificate Friendly Name and Description, in Friendly name, type Key Recovery, and then click Next.

    f. In Completing the Certificate Request Wizard, click Finish.

    g. In the console tree, double-click Personal and then click the Certificates folder.

    h. Ensure that a certificate with the friendly name of "Key Recovery" exists.

    i. Close the console without saving changes.

Task 3—Configuring the CA to allow key recovery

In this series of steps, you configure the EntCA enterprise CA to use the Recovery Agent certificate acquired in Task 2. The CA must load the public key for the Key Recovery Agent to be used for encrypting the recovery data.

Important

  • Perform the following procedures at the domain controller.

1. Configure the Recovery Agent to be the Administrator's Key Recovery Agent certificate.

    a. Ensure that you are logged on as Administrator@adventure-works.com.

    b. In Administrative Tools, open Certification Authority.

    c. In the console tree, click EntCA.

    d. Right-click EntCA, and then click Properties.

    e. On EntCA Properties, on the Recovery Agents tab, click Archive the key and then click Add.

    f. In Key Recovery Agent Selection, click the certificate that is displayed, and then click OK.

    g. When prompted to restart the CA, click Yes.

2. Open the Certificates console, focused on the local computer.

    a. On the taskbar, click the Start button, and then click Run.

    b. In Run, type mmc, and then click OK.

    c. On the File menu, click Add/Remove Snap-in.

    d. In Add/Remove Snap-in, click Add.

    e. In Add Standalone Snap-in, click Certificates, and then click Add.

    f. In Certificates, click Computer account and then click Next.

    g. In Select Computer, click Local Computer, and then click Finish.

    h. Click Close, and then click OK.

3. Verify the installation of the KRA certificate.

    a. In the console tree, double-click Certificates (Local Computer), double-click KRA, and then click Certificates.

    b. In the details pane, double-click the certificate.

    The intended use of the certificate is Key Recovery Agent and the certificate is issued to Administrator. This procedure ensures that the Key Recovery Agent has been successfully configured, and then click OK.

    d. Close the console without saving changes.

Task 4—Creating a new certificate template that allows key archiving

In this series of steps, you will define a new template that allows Key Archival by using the Certificate Templates console. This will allow key recovery in the domain in the event that the private key is lost or corrupted at the client computer.

Important: Perform the following procedures at the domain controller.

1. Open the Certificate Templates console.

    a. Log on as Administrator@adventure-works.com.

    b. On the taskbar, click the Start button, and then click Run.

    c. In Run, type mmc, and then click OK.

    d. On the File menu, click Add/Remove Snap-in.

    e. In Add/Remove Snap-in, click Add.

    f. In Add Standalone Snap-in, click Certificate Templates, and then click Add.

    g. Click Close, and then click OK.

2. Create a duplicate of the Users certificate template with the following properties:

  • Template is named "Archive User"
  • Key archival is enabled

    a. In the console tree, click Certificate Templates.

    b. In the details pane, right-click the User template, and click Duplicate Template.

    c. In the Properties of New Template dialog box, in the General tab, in the Display name box, type Archive User.

    d. In the Request Handling tab, enable the Archive subject's private key option.

    The archive key option makes it possible for the Key Recovery Agent to recover the private key from the certificate store.

    e. Click the Security tab.

    Domain Administrators and Domain Users can enroll for this certificate. These permissions were copied from the Users certificate template.

    f. Click OK.

    g. Close the console without saving changes.

Task 5—Acquiring a User certificate that has an archived key

In this series of tasks, you configure the EntCA certification authority to issue Archive User certificates. Using a newly created account, you will acquire an Archive User certificate and record the certificate's serial number for later usage.

Important

  • Perform the following procedures at the domain controller.

1. Configure EntCA to issue the new Archive User certificate template.

    a. Ensure that you are logged on as Administrator@adventure-works.com, with a password of password.

    b. From Administrative Tools, open Certification Authority.

    c. In the console tree, double-click EntCA, and then click Certificates Templates.

    d. Right-click Certificate Templates, click New, and then click Certificate to Issue.

    e. In Select Certificate Template, click Archive User and then click OK.

    The Archive User certificate template now appears in the details pane.

    f. Close Certification Authority.

2. Create a new user account

    a. In Administrative Tools, open Active Directory Users and Computers.

    b. Double-click adventure-works.com.

    c. In Users, create a user account with the following properties:

    • First name: Mike
    • Last name: Danseglio
    • User logon name: Mikedan
    • Password: password
    • Member of: Server Operators
    • E-mail: Mikedan

    d. Click Next, and then click Finish.

    e. Double-click the Mikedan account, and then select the Member of tab.

    f. Click Add, in Select Groups, type Server Operators, click Check Names, and then click OK.

    g. Click OK to close Properties.

    h. Close Active Directory Users and Computers.

    i. Close all open windows and log off of the computer.

3. Log in to the network as Mikedan@adventure-works.com and open the Certificates console.

Note

  • Mikedan was added to the Server Operators group so he can log on locally to the domain controller.

    a. Log on as Mikedan@adventure-works.com.

    b. On the taskbar, click the Start button, and then click Run.

    c. In Run, type mmc, and then click OK.

    d. From the Console menu, click Add/Remove Snap-in.

    e. In Add/Remove Snap-in, click Add.

    f. In Add Stand-alone Snap-in, click Certificates, click Add, and then click OK.

4. Use the Certificates MMC to acquire an Archive User certificate

    a. In the newly-created MMC console, in the console tree, double-click Certificates (Current User).

    b. In the console tree, right-click Personal, click All Tasks, and then click Request New Certificate.

    c. In the Certificate Request Wizard, click Next.

    d. On Certificate Template, select the Archive User certificate, and then click Next.

    e. On Certificate Friendly Name and Description, in Friendly name, type Archive User, and then click Next.

    f. On Completing the Certificate Request Wizard, click Finish.

    g. On Certificate Request Wizard, click Install Certificate and then click OK.

    h. Double-click Personal, and then click Certificates.

    i. In the details pane, double-click the certificate with the friendly name of Archive User.

    j. In Certificate, click the Details tab.

    Note that the certificate template that used to generate this certificate was ArchiveUser, then click OK.

    k. Close the new console without saving changes

    l. Close all windows and log off of the computer.

Task 6—Performing a Key Recovery

In this series of tasks, you will perform a key recovery by using Certutil.exe.

For more information on Certutil, see Certutil.

Important

  • Perform the following procedures at the domain controller.

1. Log on to the network as Administrator and ensure that the private key is still recoverable by viewing the Archived Key column in the Certification Authority console.

    a. Log on as Administrator@adventure-works.com.

    b. From Administrative Tools, open Certification Authority.

    c. In the console tree, double-click EntCA, and then click Issued Certificates.

    d. From the View menu, click Add/Remove Columns.

    e. In Add/Remove Columns, in Available Column, select Archived Key, and then click Add. Archived Key should now appear in Displayed Columns.

    f. Click OK and then, in the details pane, scroll to the right and confirm that the last issued certificate to Mikedan has a Yes value in the Archived Key column.

    Note

    • A certificate template must have been modified so that the Archive bit and Mark Private Key as Exportable attributes were enabled. The private key is only recoverable if there is data in the Archived Key column.

    g. Double-click the Archive User certificate.

    h. Click the Details tab

    Write down the serial number of the certificate. (Do not include spacing between digit pairs.) This is required for recovery.

    The serial number will be a hexadecimal string that is 20 characters long. The serial number of the private key is the same as the serial number of the certificate. For the purposes of this walkthrough, the serial number will be referred to as serialnumber.

    i. Click OK.

    j. Close Certification Authority.

2. Recover the private key into a BLOB output file by using certutil.exe.

    a. On the taskbar, click the Start button, click Run, type cmd, then click OK.

    This opens a command prompt window.

    b. Type cd \ and then press ENTER.

    c. Ensure that you are in the c:\ directory.

    d. At the command prompt, type:

    Certutil -getkey serialnumber outputblob

    e. At the command prompt, type dir outputblob

    Note

    • If the file outputblob does not exist, you probably typed the serial number incorrectly for the certificate.

    The outputblob file is a PKCS#7 file containing the KRA certificates and the user certificate and chain. The inner content is an encrypted PKCS#7 containing the private key (encrypted to the KRA certificates).

3. Recover the original private/public key pair using Certutil.exe

    a. On the taskbar, click the Start button, click Run, type cmd, then click OK.

    This opens a command prompt window.

    b. At a command prompt, type:

    Certutil -recoverkey outputblob Mikedan.pfx

    c. When prompted, enter the following information:

    Enter new password: password

    Confirm new password: password

    d. Type exit, and then press ENTER.

    e. Close all windows and log off as the current user.

Task 7—Importing the recovered private key

In this series of tasks, you will restore the recovered private key in Mike's certificate store by importing the Mikedan.pfx file.

Important

  • Perform the following procedures at the domain controller.

1. Log on as Mikedan@adventure-works.com and start the Certificates mmc.

    a. Log on as Mikedan@adventure-works.com, with a password of password.

    b. On the taskbar, click the Start button, and then click Run.

    c. In Run, type mmc, and then click OK.

    d. On the File menu, click Add/Remove Snap-in.

    e. In Add/Remove Snap-in, click Add.

    f. In Add Standalone Snap-in, click Certificates, click Add,and then click OK.

2. Delete all certificates issued by EntCA to simulate a re-installed computer.

    a. Right-click Certificates (Current User), and then click Find Certificates.

    b. In Find Certificates, in Contains, type EntCA and then click Find Now.

    c. In Find Certificates, on the Edit menu, click Select All.

    d. In Find Certificates, on the File menu, click Delete.

    e. In Certificates, click Yes.

    f. In Root Certificate Store, click Yes.

    g. Close Find Certificates.

3. Import the certificate at c:\Mikedan.pfx and let the certificates be placed automatically.

    a. In the console tree, right-click Personal and then click All Tasks and then click Import.

    b. In the Certificate Import Wizard, click Next.

    c. On Files to Import, in the File name box, type c:\Mikedan.pfx, and then click Next.

    d. In Password, type password and then click Next.

    e. On Certificate Store, click Automatically select the certificate store based on the type of certificate and then click Next.

    f. On Completing the Certificate Import Wizard, click Finish

    g. If the Root Certificate Store dialog box appears, click Yes.

    h. In Certificate Wizard Import, click OK.

    Two certificates were imported. The Archive User certificate for Mike is located in the Personal certificates store and the EntCA certificate is located in the Trusted Root Certification Authorities store.

4. Verify the serial number of the imported certificate.

    a. In the console tree, double-click Personal and then click Certificates.

    b. Double-click the certificate

    c. In Certificate, click the Details tab. Verify that the serial number matches the original.

    d. Close all open windows and log off of the network.


Using qualified subordination

This section covers:

  • Qualified subordination overview
  • Name constraints
  • Mapping policies between trust hierarchies
  • Policy constraints


Qualified subordination overview

Qualified subordination allows you to place certificate issuance constraints on subordinate CAs and to place usage constraints on the certificates they issue. With qualified subordination, you can focus subordinate CAs according to specific certification needs and administer your public key infrastructure (PKI) more efficiently.

Certificate-based trust between trust hierarchies

Qualified subordination also allows you to establish trust between CAs in separate trust hierarchies. This type of trust relationship is also called cross-certification. With this trust relationship, qualified subordination is not limited to subordinate CAs. Trust between hierarchies may be established using a subordinate CA in one hierarchy and the root CA in another hierarchy.

Additional levels of security controls

Qualified subordination extends your trust hierarchy by allowing you to place additional trust conditions within and between the domains in your PKI. With qualified subordination, the qualified subordinate CAs in your trust hierarchy can each have different rules governing how they will issue certificates and how their certificates may be used. For more information on qualified subordination, see Qualified subordination.

Qualified subordination extensions

Each qualified subordination constraint adds an additional trust condition and more narrowly defines the scope of a CA. These conditions are defined in the certificate extensions of a qualified subordinate CA certificate. When you install a qualified subordinate CA, you define the following extensions in its CA certificate:

Extension | Description
Name Constraints | Restricts the namespaces that are permitted or excluded by the qualified subordinate CA and its subordinates when issuing certificates.
Policies | Defines the list of acceptable issuance and application policies for certificate usage. These policies are identified in the certificate by object identifiers (also known as object identifiers).
Policy Mapping | Allows a policy from one domain to be mapped onto a policy of another domain.
Policy Constraints | Restricts the subordination levels in a certificate hierarchy to which a policy is applied. These extensions are used in conjunction with issuance and application policies only.

All constraints that are placed on a qualified subordinate CA are defined in the complete request for the CA certificate that is used to install the qualified subordinate CA. The complete request is a CMC certificate request that has been generated using an information file (.inf file). All qualified subordinate CA policies, constraints, and mappings can be defined using an information file (.inf). In order to modify the policies and constraints placed on a qualified subordinate CA after installation, the administrator of that qualified subordinate CA's parent CA must reissue the CA certificate for the qualified subordinate CA, thereby reinstalling it. For more information, see To perform qualified subordination.

The constraints and policy types listed above are defined in RFC 2459. For more information on RFCs, see the RFC Editor Web site.

For more information, see Name constraints, Policy constraints, Mapping policies between trust hierarchies, and Policy qualifiers.

Qualified subordinate CA scenarios

The following sections show how qualified subordination can be used.

Name constraints scenarios

The Humongous Insurance Company has two Active Directory directory service domains hosted in different geographic locations, one domain in North America and one domain in South America. The company's PKI administrator wants the qualified subordinate CAs that are deployed in each domain to issue certificates for users in their local domain only. The two Active Directory domains are northamerica.humongousinsurance.com and southamerica.humongousinsurance.com.

The administrator performs the following steps:

  1. Installs a qualified subordinate CA for the domain northamerica.humongousinsurance.com with the following permitted name constraints:
    Name constraint format | Permitted name constraint | Example
    Distinguished name | DC=northamerica,DC=humongousinsurance,DC=com | CN=Mike Danseglio,CN=Users,DC=northamerica,DC=humongousinsurance,DC=com
    DNS domain name | .northamerica.humongousinsurance.com | hostname.northamerica.humongousinsurance.com
  2. Installs a qualified subordinate CA for the domain southamerica.humongousinsurance.com with the following permitted name constraints:
    Name constraint format | Permitted name constraint | Example
    Distinguished name | DC=southamerica,DC=humongousinsurance,DC=com | CN=Don Funk,CN=Users,DC=southamerica,DC=humongousinsurance,DC=com
    DNS domain name | .southamerica.humongousinsurance.com | hostname.southamerica.humongousinsurance.com

As a result, the certificate issuance behavior of each qualified subordinate CA is restricted to users in their respective domains. If a user in northamerica.humongousinsurance.com requests a certificate from the qualified subordinate CA for southamerica.humongousinsurance.com, the request is denied because the namespace specified in a permitted name constraint automatically excludes any other namespaces.

For more information, see Name constraints.

Policy scenarios

Humongous Insurance wants to use application and issuance policies to configure the following PKI scenarios:

  • Only allow remote network logon using smart card authentication.
  • Create a certificate that allows selected users to make purchases of up to one million dollars.

Only allow remote network logon using smart card authentication

To restrict remote network logon to only allow smart card authentication, the company performs the following steps:

  1. Configures their remote access server to require smart card authentication.
  2. Installs and configures a qualified subordinate CA to issue smart card logon certificates containing a specific application policy that is required by the remote access server.
  3. Distributes smart cards containing the specific application policy that is required by the remote access server.

When a user attempts to log in, the following steps occur:

  1. Users attempt to log on remotely over a dial-up connection using their smart cards.
  2. The remote access server software checks to see if the smart card contains the required application policy.
  3. If the smart card contains the required application policy, then the remote access server software forwards the logon request to the nearest domain controller.
  4. The domain controller grants the user access to the network.

Create a certificate that allows selected users to make purchases of up to one million dollars

To create a certificate that allows selected users to make purchases of up to one million dollars, the company performs the following steps:

  1. Creates a signing certificate for the company’s accounting department that contains a specific issuance policy object identifier (also known as an OID).
  2. When the company creates a Million Dollar Purchase certificate template, it adds an issuance requirement for the Accounting department’s specific issuance policy object identifier.
  3. The user creates a million dollar purchase request using the template.
  4. The accounting department manager is notified that there is a pending certificate request which she must accept or reject.
  5. The accounting department manager signs the Million Dollar Purchase certificate request with the signing certificate that contains the specific issuance policy object identifier.
  6. The signed request is sent to the company's CA.
  7. The company’s CA receives the signed request, determines that the issuance requirement for the certificate template has been met by identifying the accounting department’s specific issuance policy object identifier, and issues the Million Dollar Purchase certificate to the user.

Policy mapping scenario

Two companies, Humongous Insurance and Northwind Traders, enter into a partnership and want to establish a trusted communication path where the $1 million issuance policy of Humongous Insurance is considered equal with the two million dollar issuance policy of Northwind Traders.

The CA administrator for the Humongous Insurance domain humongousinsurance.com performs the following steps:

  1. Obtains the two million dollar issuance policy object identifier for Northwind Traders under a very secure channel.
  2. Defines the policy mapping between Humongous Insurance's one million dollar issuance policy and Northwind Traders' two million dollar issuance policy.
  3. Installs a qualified subordinate CA in the Humongous Insurance trust hierarchy containing the policy mapping.

The policy mapping results in allowing purchase orders signed in the Northwind Traders trust hierarchy to be validated by the trust hierarchy of Humongous Insurance.

For more information, see Mapping policies between trust hierarchies; Policy constraints

Enterprise and stand-alone qualified subordinate CAs

Windows Server 2003 qualified subordinate CAs can be installed as enterprise qualified subordinate CAs or stand-alone qualified subordinate CAs. The difference between the two types of qualified subordinate CAs is how they identify users requesting certificates. Enterprise qualified subordinate CAs require the use of Active Directory and stand-alone qualified subordinate CAs do not.

Enterprise qualified subordinate CAs identify users by some or all of their Active Directory user object attributes. When an enterprise qualified subordinate CA receives a certificate request from a user, it identifies the user according to the authentication credentials that are used by that user during network logon and uses that information to query the Active Directory and obtain the user's user object attributes.

When users request certificates from a stand-alone qualified subordinate CA, the user fills out a Web page form where the user specifies information such as a name, e-mail address, company name, department, and country/region. This information is included in the fields of the certificate request that is sent to the stand-alone qualified subordinate CA, which uses this information to determine certificate issuance. A stand-alone CA cannot publish any issued certificates to Active Directory other than its own CA certificate. However, the more common scenario is to have a stand-alone root CA with an enterprise qualified subordinate CA. For more information, see Stand-alone certification authorities.

Verification paths for qualified subordinate CAs

Each qualified subordinate CA's policies and constraints are defined according to a subset of its certification path's policies and constraints. Using qualified subordination, boundaries are established within the certification hierarchy to ensure that all CAs in a hierarchy's paths issue certificates within certain constraints. These constraints may be maintained or more narrowly defined the further the certification hierarchy branches from its trust anchor (root CA).

The following graphic shows how qualified subordinate CAs can only issue CA certificates according to a subset of the rules permitted by their certification path. In the graphic, policies are used as an example and are represented as numbers to demonstrate a subset.

Qualified subordination certification hierarchy restrictions

Qualified subordinate CAs CA 1, CA 2, and CA 3 have defined policies from which the qualified subordinate CAs below them may select policies. With each level of the certificate hierarchy, fewer of the acceptable policies are used and the qualified subordinate CAs are more limited in scope.

No trust model will permit the qualified subordinate CA to allow certificate issuance behavior that its certificate path does not allow. To enforce this rule, the following process is followed when a parent CA receives a CA certificate request:

  1. The CA verifies the certificate request against all the constraints placed on all the CAs from its root CA down its certification hierarchy to itself.
  2. At each intersection in the certification hierarchy, the issuing qualified subordinate CA compares the information contained in the certificate request with those set at the existing CA.
  3. If there are no conflicts between the information in the certificate request and those placed on the CAs in the certification hierarchy, then the certificate is issued. If there is a conflict, the certificate request is denied.

Notes

  • XOX
  • In addition to the new constraints discussed in this topic, basic constraints can be used to control how a CA issues certificates. Basic constraints are available in both Windows 2000 and Windows Server 2003 CAs. For more information, see Basic constraints and Change basic constraints.


Name constraints

You can use qualified subordinate certification authority (CA) name constraints to restrict a qualified subordinate CA's certificate issuance authority to single or multiple namespaces used within your network or public key infrastructure (PKI), such as those used as Active Directory domains. By constraining the qualified subordinate CA's certificate issuance according to one or more namespaces, you will have greater control over which users and computers receive certificates from your qualified subordinate CAs. For more information, see Qualified subordination.

You can use the following naming and addressing formats to constrain the certificate issuance activities of qualified subordinate CAs:

  • Directory name (for example, an Active Directory distinguished name)
  • DNS domain name
  • E-mail name
  • User principal name (UPN)
  • Universal Resource Identifier (URI)
  • Internet Protocol address

The qualified subordinate CA's name constraints define namespaces within which all user names identified in the certificate requests it receives must be located. Name constraints are organized as permitted or excluded name constraints. If the same name formats used as name constraints are present in the certificate requests received by the qualified subordinate CA, it evaluates them according to its permitted and excluded name constraints.

When using qualified subordination in your PKI deployment, you can leverage the well-planned naming and addressing methods used in your network to support the goals of your PKI. In a sense, you can imprint your trust model onto these existing methods, assigning CAs to different domains and configuring them to issue certificates only to users and computers in those domains. When you deploy a qualified subordinate CA to a network domain, you will need to consider the namespaces and addressing methods used by the resources of that domain, and possibly subdomains and other domains, in order to configure the qualified subordinate CA to issue certificates according to your administrative and security goals.

Choosing permitted and excluded name constraints

When choosing a qualified subordinate CA's name constraints, you need to decide on the users that the qualified subordinate CA will receive certificate requests from. Typically, the qualified subordinate CA will be deployed to an Active Directory domain in your network and be responsible for issuing certificates to the users and computers within that domain and possibly its subdomains. The namespaces used by these domains, including Active Directory names, DNS namespaces, and other namespaces, can be used to define the permitted and excluded name constraints of the qualified subordinate CA.

Excluded name constraints are used to exclude a child namespace of a permitted namespace. For example, your qualified subordinate CA may have a permitted name constraint for the DNS namespace .microsoft.com, but you do not want it to issue certificates for the subdomain .betatest.microsoft.com because that subdomain may be experimenting with software that should not be certified within your PKI. An excluded name constraint of .betatest.microsoft.com removes the qualified subordinate CA's ability to issue certificates to users and computers within the namespace .betatest.microsoft.com.

If an excluded name constraint is used to exclude a parent namespace of a permitted name constraint, it will exclude the entire permitted namespace. For example, if a permitted name constraint is .example.microsoft.com and the excluded name constraint is .microsoft.com, then the entire .microsoft.com namespace is excluded.

It is also important to note that excluded namespaces take precedence over permitted namespaces, guaranteeing that the qualified subordinate CA will not issue a certificate to a user within an excluded namespace even if the user is also within a permitted namespace. For example, a user could be within the permitted Active Directory namespace .microsoft.com but also within the excluded DNS namespace .widgets.microsoft.com. In this example, the excluded DNS namespace overrides the permitted Active Directory namespace and the qualified subordinate CA does not fulfill the user's certificate request.

When choosing permitted and excluded name constraints, you should be aware of how the qualified subordinate CA processes certificate requests. When the qualified subordinate CA is comparing the names identified in a certificate request to its name constraints, all names in a certificate request must be within permitted namespaces and none may be within an excluded namespace. For more information on how a qualified subordinate CA using name constraints when processing certificate requests, see Name constraint processing rules.

Directory name constraints

Active Directory allows you to use distinguished names as name constraints for your qualified subordinate CAs. Distinguished names identify users and resources on the network in Active Directory. This allows you to constrain a qualified subordinate CA to permit or exclude users in the Active Directory using the users' distinguished names. Active Directory also uses distinguished names to create and reference groups of objects in the directory, such as users and computers. The distinguished names of these object groups can also be used as name constraints, allowing you to constrain a qualified subordinate CA to permit and exclude certificate issuance for entire groups in the directory.

The following table describes types of distinguished names that are used as permitted and excluded names.

Directory object | Distinguished name constraint examples
User | CN=Users,DC=example,DC=microsoft,DC=com
Computer | CN=Computers,DC=microsoft,DC=com
Domain controller | CN=Servers,CN=Sites,CN=Configuration,DC=microsoft,DC=com
Contact | OU=Contacts,DC=microsoft,DC=com
Group | OU=My Group,DC=microsoft,DC=com
Organizational Unit | OU=ITServices,DC=microsoft,DC=com

X.500 directory names can also be used as name constraints. For example, o=cities,st=Redmond,c=US.

DNS name constraints

You can apply the DNS namespaces used by your network for name resolution as name constraints for a qualified subordinate CA. When the qualified subordinate CA receives a certificate request, it will compare the DNS name associated with the computer requesting the certificate to its DNS name constraints and decide whether or not to issue a certificate. The subordinate CA will apply name constraints to all entities within the DNS namespaces specified as DNS name constraints. The DNS domain names accepted by the subordinate CA must follow the standard DNS naming conventions as specified in RFCs 1034 and 1035. The permitted and excluded DNS name constraints are specified using the information file (.inf) that is used to install the qualified subordinate CA.

There are two different ways to specify a DNS name constraint:

  • DNS host name. Specifies a specific DNS host name as a permitted or excluded name constraint, such as host1.example.microsoft.com.
  • DNS namespace. Specifies a DNS name space wherein all DNS host names are permitted or excluded, such as .example.microsoft.com.

To specify that a DNS name constraint should apply to all entities within a DNS namespace and not host names containing part of the name, you must use a period (.) after the leftmost label in the domain name, such as .example.microsoft.com. This period indicates that all subjects with a DNS name ending in the domain .example.microsoft.com are subject to the DNS name constraint, but the host name host1example.microsoft.com is not a match because host1example contains no period separator between host1 and example.

When the subordinate CA compares the DNS name in a certificate request with its name constraints, it performs a string comparison. The string comparison attempts to locate a match within any part of the names. If the qualified subordinate CA's DNS name constraint is example.microsoft.com and the certificate request contains a DNS host name host1example.microsoft.com, the qualified subordinate CA will consider those names as a match. Using the same DNS name constraint (example.microsoft.com), the domain name www.example.microsoft.com is also considered a match.

With DNS name constraints involving domain names, any subdomain of a name constraint satisfies the constraint. If you apply an excluded DNS name constraint for .example.microsoft.com (notice the leftmost period), then names such as www.example.microsoft.com and us.sales.example.microsoft.com are excluded also. Using the same excluded DNS name constraint, names such as it.microsoft.com and accounts.microsoft.com would not be excluded.

The following table demonstrates the two different DNS name constraint evaluation methods used by a qualified subordinate CA.

Certificate request's DNS information | DNS constraint | Qualified subordinate CA evaluation
host1example.microsoft.com | .example.microsoft.com | No match
host1.example.microsoft.com | .example.microsoft.com | Match
www.example.microsoft.com | .example.microsoft.com | Match
us.sales.example.microsoft.com | .example.microsoft.com | Match

When creating DNS constraints, you should consider the hierarchies of the DNS namespaces to avoid conflicts between permitted and excluded DNS constraints. If you are permitting and excluding DNS domains for a qualified subordinate CA, the excluded domain names override the permitted names. If you specify the permitted DNS name constraint www.example.microsoft.com and also specify the excluded DNS name constraint .microsoft.com, the permitted name will be cancelled out by the excluded name because the permitted domain name is a subdomain of the excluded domain name.

A qualified subordinate CA's DNS constraints cannot permit DNS names excluded by its parent CA. For example, if the parent CA excludes the DNS name .microsoft.com, then its qualified subordinate CA cannot permit the subdomain www.example.microsoft.com.

URI constraints

You can specify Uniform Resource Identifiers (URIs) as name constraints for a qualified subordinate CA. URIs are used to identify resources on the Internet using identifiers such as URL, FTP, HTTP, telnet, mailto, news, and gopher. The URI naming conventions supported by the qualified subordinate CA must follow the syntax specified in RFC 2396.

When validating the URI names in a certificate request, the qualified subordinate CA ignores the protocol element in the URI, such as http:// or ftp://, and uses the domain or host names only. For example, if the URI constraint URL=http://.example.microsoft.com is compared to the name ftp://host1.example.microsoft.com, then the comparison is actually between the URI constraint .example.microsoft.com and the name host1.example.microsoft.com.

Similar to DNS constraints, URI constraints may specify a host or domain. When specifying a domain, URI name constraints must begin with a period (.), such as .example.microsoft.com. This URI constraint also applies to all subdomains of the domain constraint, such as abc.example.microsoft.com or xyz.example.microsoft.com. Using the same example, if the URI name in a certificate request does not contain a period to the left of example, then the constraint does not apply. For example, the certificate request URI name example.microsoft.com (notice that there is no beginning period) does not satisfy the name constraint .example.microsoft.com.

When specifying a host, the beginning period is not used, such as host1example.microsoft.com. Without the beginning period, the name constraint is satisfied only when the subject in the certificate request has the leftmost label (host1example). For example, the name constraint example.microsoft.com would be satisfied by the certificate request name host1example.microsoft.com but not by host1.example.microsoft.com.

The most frequent application of URI name constraints is the validation of certificate requests for subjects wanting to access to a secure Web server. For example, if the Web server certificate request has a name of http://www.microsoft.com and the qualified subordinate CA's permitted URI name constraint is URL=http://www.microsoft.com, then this URI constraint would permit the certificate request for the Web server certificate.

E-mail and UPN constraints

Both e-mail and UPN naming conventions follow a similar format that must be followed when you format name constraints. E-mail extensions and UPNs used as name constraints follow the naming conventions specified in RFC 822.

You can specify e-mail and UPN name constraints for an individual subject, such as mikedan@example.microsoft.com, or you can specify constraints for all subjects whose e-mail names or UPNs end in a specific name, such as @example.microsoft.com. Typically, you will specify e-mail or UPN name constraints for all subjects whose e-mail addresses and UPNs end in a specific name.

The difference in specifying these two name constraints is the at sign (@). If the name constraint contains any characters to the left of the @, the qualified subordinate CA regards the name constraint as applying to a single subject. Conversely, if there are no characters to the left of the @, then the qualified subordinate CA regards the name constraint as applying to all subjects whose e-mail addresses or UPNs end in the name constraint.

E-mail and UPN constraints | Certificate name value | Qualified subordinate CA's evaluation
host1@example.microsoft.com | host1@example.microsoft.com | Match
@example.microsoft.com | host1@example.microsoft.com | Match
host1@example.microsoft.com | mikedan@example.microsoft.com | No match

Note

  • If UPN and e-mail permitted name constraints are not defined when defining the permitted name constraints for a qualified subordinate CA certificate request, then the UPN and e-mail permitted name constraints are automatically entered by the issuing CA's policy module when it creates the qualified subordinate CA certificate. The UPN and e-mail permitted name constraints are left unspecified and therefore permit all names. If you want to apply UPN and e-mail permitted name constraints, you must specify the UPN and e-mail permitted constraints when defining the permitted name constraints for a qualified subordinate CA certificate request.

IP address constraints

You can specify IP addresses and IP address ranges as name constraints on a qualified subordinate CA. IP address name constraints follow the formatting conventions specified in RFCs 791 (IPv4) and 1883 (IPv6). The IP addresses that are contained in the certificate requests that are made to a qualified subordinate CA will be compared to the IP addresses in the qualified subordinate CA's name constraints.

Name constraint processing rules

For a certificate request to be successful, all names that are identified in a certificate request must be within permitted name spaces and none may be within an excluded namespace. Each permitted and excluded name constraint is processed separately.

Name constraints are processed by the qualified subordinate CA according to the following rules:

  • Constraints apply only when the namespace types specified as name constraints are present in the certificate request.
  • A certificate request is successful if all names in the certificate request succeed in matching the permitted name constraint.
  • A certificate request is unsuccessful if all names in the certificate request succeed in matching the excluded name constraint.
  • A certificate request containing names that can not be matched with either the permitted or excluded names is considered excluded and is failed.
  • Comparison of the name identifying the subject entity with the qualified subordinate CA's name constraints is performed using Unicode. The comparison is not case sensitive.

To find a match, the qualified subordinate CA starts at the rightmost part of the name in the certificate request and compares that name to its list of permitted and excluded name constraints. For example, when the CA receives a certificate request with the DNS name example.microsoft.com it will attempt to find a name constraint match starting with .com, then microsoft.com, and then example.microsoft.com. The exceptions to this are distinguished names (DNs), where the qualified subordinate CA starts from the leftmost name, and IP addresses, where it attempts to find a match starting with the network address and then the host address.

For a certificate request to be accepted by the qualified subordinate CA, each name in the certificate request should match at least one of the qualified subordinate CA's name constraints of the same name type. If there are two permitted distinguished names on the qualified subordinate CA, then the certificate request subject's name should match at least one of these distinguished names. No comparisons are performed between different types of names.

Excluded names take precedence over permitted names. If a permitted DNS name constraint allows users from the DNS domain .example.microsoft.com, but the same name is listed as an excluded name constraint, then users from the DNS domain .example.microsoft.com are excluded and the qualified subordinate CA will fail their certificate requests. This processing rule requires that you pay close attention to the hierarchy of the different name conventions. For example, if a permitted DNS name constraint permits users from the DNS domain .example.microsoft.com, but the parent domain .microsoft.com is listed as an excluded name constraint, then users from the DNS domain .example.microsoft.com are excluded because .example.microsoft.com is a child domain of .microsoft.com.


Mapping policies between trust hierarchies

To establish trust between users and computers in different trust hierarchies, you can map the issuance and application policies of each trust hierarchy. The qualified subordinate CA that contains this mapping is called the issuer CA and the subordinate CA whose policies have been mapped is called the subject CA. In mapping some or all of the subject CA's policies to the issuer's policies, the issuer CA effectually subordinates the subject CA. The result of this mapping is that users and computers in the issuer CA trust hierarchy who attempt to validate certificates from users and computers in the subject CA trust hierarchy can use their own certification path to perform validation. The separate trust hierarchy can be within the same intranet or in separate PKI environments over an extranet.

Mapping policies across trust hierarchies only requires that you install the issuer CA in your trust hierarchy. All the policies that are used in the subject CA trust hierarchy are mapped to the policies in your trust hierarchy, where you install the qualified subordinate CA. For this reason, you can establish a trust relationship, in fact subordinate, with a CA in another company by obtaining its policy object identifiers (also known as OIDs) and mapping them to the policy object identifiers that are used in your trust hierarchy.

The following steps are performed when using policy mapping for both issuance and application policies:

  1. Determine the trust hierarchy with which you want to establish a trust relationship.
  2. Establish the equivalence between the assurance levels that are used between the two trust hierarchies involved in the trust relationship.
  3. Obtain the issuance and application policy object identifiers that are used in both trust hierarchies involved in the trust relationship.
  4. Map the issuance and application policy object identifiers in the separate trust hierarchies and define their policy constraints in the CA certificate request for the qualified subordinate CA you are installing in your trust hierarchy.
  5. Install the qualified subordinate CA with the policies, policy mappings, and policy constraints in your trust hierarchy.

When a user in the issuer CA trust hierarchy receives a file signed by a user in the subject CA trust hierarchy, the application of the user in your domain will attempt to validate the certificate using the validation path in your trust hierarchy. Because the object identifier in the certificate maps to an object identifier in your trust hierarchy, the certificate is validated. When a user in the subject CA trust hierarchy receives a file signed by a user in the issuer CA trust hierarchy, the subject CA user's application will attempt to validate the certificate using the validation path in its own certification hierarchy. Because the certificate contains the object identifiers used in the subject CA trust hierarchy, the certificate is validated.

Before defining the policy mapping, you need to obtain all the object identifiers that will correspond between the domains in the trust relationship. If you are creating a qualified subordinate CA for the purpose of establishing a trust relationship between trust hierarchies in different companies or PKIs, you will need to obtain the object identifiers used in the subject CA trust hierarchy by obtaining a certificate used in that hierarchy or from the CA administrator of that hierarchy. This information should only be passed under the most secure channels.

Issuance policy object identifiers in your trust hierarchy can only be mapped to issuance policy object identifiers in the foreign trust hierarchy. Similarly, application policy object identifiers in your trust hierarchy can only be mapped to application policy object identifiers in the foreign trust hierarchy.

For more information, see Qualified subordination; Qualified subordination overview; Name constraints; Issuance policies; Application policies; Policy constraints; Policy qualifiers; and Certificate Templates.

Constraining policy mapping

When a qualified subordinate CA uses policy mapping, you can use policy constraints to set the number of subordinate CAs below it in the certificate hierarchy that may map to its policies. An inhibit policy mapping policy constraint of 3 will inhibit policy mapping to subordinate CAs four levels below the qualified subordinate CA. A subordinate CA 5 levels below the qualified subordinate CA will not be allowed to define policy mappings.

Unexpected trust

When mapping policies between trust hierarchies in two different companies, the problem of unexpected trust could arise should a third company map its policy object identifier to the mapped object identifier of one of the two companies. For example:

  • The secure e-mail policy used by humongousinsurance.com is mapped to the secure e-mail policy in wideworldimporters.com.
  • A third company, northwindtraders.com, maps its secure e-mail policy to the policy of wideworldimporters.com.
  • This allows a user in northwindtraders.com to send signed e-mail to humongousinsurance.com that is considered valid because the e-mail application in humongousinsurance.com sees its own valid policy object identifier in the certificate issued by the CA in northwindtraders.com.

If humongousinsurance.com wants to prevent any additional policy mapping by northwindtraders.com from affecting its domain, it could place an inhibit policy mapping of 0 on its issuer CA. The CA for northwindtraders.com is considered a subordinate of the CA for wideworldimporters.com, and is thereby two levels below the issuer CA for humongousinsurance.com. Consequently, an inhibit policy mapping of 0 would cause the qualified subordinate CA for humongousinsurance.com to only process the policy mapping in certificates from subjects directly below it in its trust model (wideworldimporters.com) and refuse any certificates issued below that level (northwindtraders.com).


Policy constraints

Qualified subordinate certification authority (CA) policy constraints allow you to constrain the path validation of your certification hierarchy by:

  • Defining how far below a qualified subordinate CA in your certification hierarchy that a policy is required.
  • Defining how far below a subordinate CA in your certification hierarchy that policy mapping is permitted.

There are two policy constraint settings:

  • Require explicit policy. Determines the maximum number of additional certificates that may appear below the qualified subordinate CA in the certification hierarchy before a policy is required.
  • Inhibit policy mapping. Determines the maximum number of additional certificates that may appear below the qualified subordinate CA in the certification hierarchy before policy mapping is no longer permitted.

Policy constraints are set separately for issuance and application policies. The policy constraints for a qualified subordinate CA's issuance policies do not have to be the same as the Require explicit policy and Inhibit policy mapping settings for its application policies.

When defining policy constraints, the numbering system used begins with 0. For example, if a qualified subordinate CA policy has an inhibit policy mapping of 0, then that policy can only be mapped one level below the qualified subordinate CA in the trust hierarchy.

For more information, see Qualified subordination; Qualified subordination overview; Name constraints; Mapping policies between trust hierarchies; Policy qualifiers; and Certificate Templates.

Note

  • Policy constraints cannot be specified in certificate templates, but must be specified in the information file (.inf) used to create the CA certificate that, in turn, is used to install the qualified subordinate CA.


Troubleshooting

What problem are you having?

Clients do not automatically enroll for certificates after autoenrollment is configured.

Cause: The Group Policy information used for autoenrollment has not yet replicated to the client computers. By default, this information can take up to 120 minutes to replicate to all computers.

Solution: Wait for Group Policy to complete replication or use the Gpupdate tool to force replication to occur immediately.

General troubleshooting for a certification authority (CA).

Check the event log of the server. It often logs more detailed errors than you will notice from doing the procedure you're attempting.

For more information about Certificate Services logging, see article Q305018, "How to Change the Event Logging Level for Certificate Services," in the Microsoft Knowledge Base. (http://www.microsoft.com/)

Error when accessing the certification authority Web pages.

Cause: The user accessing the Web pages is not a member of the Administrators or Power Users groups on the local computer. When a newer version of the Web enrollment software is available on the CA, the client computer must install that software. The user must be a member of the Administrators or Power Users group to install the software.

Solution: Log on as a user that is a member of the Administrators or Power Users group to access the Web enrollment pages and download the newer version of the software.

Cause: Web pages aren't installed on the certification authority (CA).

Solution: From the command prompt on the CA, run certutil -vroot to install the Web enrollment pages.

Cause: Web pages don't have execute script permissions.

Solution: From Internet Information Services (IIS), open the CertSrv folder and confirm that there are execute script permissions on the folder. The CertSrv folder is:

Systemroot/System32/Certsrv

Web pages on an enterprise certification authority (CA) either don't generate certificates or generate certificates that are not valid.

Cause: For an enterprise CA, Web pages require that the user be authenticated. If the pages are set to allow anonymous connections, then the CA will either not generate certificates or will generate certificates that are not valid.

Solution: See Set security for access to certification authority Web pages.

Can't log into certification authority (CA) Web pages.

Cause: If the Web pages negotiate basic authentication with the browser, then your Windows 2000 user account must have the user right to log on to the server.

Solution: By default, only domain administrators have this user right. You will need to change this default security permission setting for the server hosting the CA if you use the Netscape browser.

Certification authority (CA) Web enrollment pages that are installed on a remote server other than the CA do not work.

Cause: The pages are set to use NTLM authentication instead of basic authentication.

Solution: If the Web pages are located on a different server than the CA, then you must set the pages to use basic authentication rather than NTLM if the CA is an enterprise CA. You should also use Secure Sockets Layers (SSL) to secure these pages to protect the passwords. See the Internet Information Services (IIS) documentation to change these settings.

Internet Information Services (IIS) 4.0 and Certificate Server 1.0 cannot enroll for certificates using XOX; XOX; and XOX Certificate Services Web pages.

Cause: IIS 4.0 and Certificate Server 1.0 cannot process a certification path, rather than just a single certificate.

Solution: Use the command-line utility CertReq to process the enrollment request.

A user tries to log on with the smart card and receives this message: "The system cannot log you on to this domain because the system's computer account in its primary domain is missing or the password on the account is incorrect."

Cause: The computer account may be disabled or the CA that issued the smart card certificate is not trusted by the computer.

Solution:

  1. Make sure that the computer account is enabled in the domain.
  2. Use the Certificates snap-in to verify that the root CA's certificate is in the Trusted Root Certification Authorities store on the user's computer.
  3. Use the Certificates snap-in to verify that the domain controller has been issued a domain controller certificate that can be verified to a trusted root.

After renewing a CA, computers are no longer automatically enrolling for certificates from that CA.

Cause: CA renewal requires that all automatic certificate enrollment objects that enroll for certificates from that CA be recreated.

Solution: See Create an automatic certificate request for computers in a Group Policy object.

When trying to enroll for a certificate from a computer or account belonging to a child domain of the domain where the CA is located, the following error appears: "No template could be found. There are no CAs from which you have permission to request a certificate, or an error occurred while accessing the Active Directory."

Cause: You don't have the proper security permissions set on the certificate templates.

Solution: Modify the security permissions for the certificate templates to include the child domain accounts from which you want to allow enrollment. To set access control for certificate templates , see Controlling enrollment access to certificate templates. Some access control caches must time out after making changes to security permissions, so you have to wait a short period of time before seeing the new security permissions replicate through the network.


Policy qualifiers

The issuance and application policy settings used by a qualified subordinate certification authority (CA) can also contain policy qualifiers. Policy qualifiers provide information or links to information about the policy published by the CA. There are two types of policy qualifiers supported in the Certificate Policies certificate extension: the Certification Practice Statement (CPS) qualifier and the User Notice qualifier. The Certification Practice Statement (CPS) qualifier is in the format of a URI, such as a URL to a Web page containing the CPS. The User Notice qualifier can be composed of a notice reference, a text message up to 200 characters containing the actual notice, or both.

When subjects view a certificate using an application, they can follow the URL and read the description of the issuance policy in a Web browser. If a text message is used as a policy qualifier, the application will display the message.


Using role separation

Role separation enforces the separation of the certification authority (CA) roles that are defined in role-based administration. When enabled, role separation enforces that a user with more than one CA role cannot perform any CA operation. Without enabling role separation, a single user can be assigned multiple CA roles. For more information on role-based administration, see Role-based administration.

In large enterprises, there may be many groups assigned CA roles on a CA. If a user belonging to these groups is assigned multiple CA roles and the user's account is compromised, then the operation of the CA may also be compromised. Enforcing the separation of CA roles so that each user holds only a single role ensures that if one user's account is compromised, then the operation of the entire CA is not compromised.

Important

  • Before role separation is enabled, each user assigned a CA role on the CA must only be assigned a single CA role on that CA. If a user is assigned more than one CA role, when role separation is enabled, the Certificate Services service will detect that a user has more than one role and deny the user's attempts to operate the CA.

Enabling role separation

You must enable role separation on each CA to enforce the separation of roles. Only members of the local Administrators security group on a CA can enable and disable role separation. Enabling role separation requires editing the registry of the XOX running the Certificate Services service. Once this registry setting is edited to enable role separation, any assigned roles are in effect until the local Administrator of the server disables role separation through the registry. For more information, see To enable role separation.

CA roles can be assigned and changed by the CA Administrator while role separation is enabled or disabled. While role separation is enabled the CA Administrator cannot assign a user to more than one CA role. If the CA Administrator attempts to assign a user to a second CA role, the operation is refused.

Role separation concerns

It is possible for a user assigned a role to become locked out of administering a CA when role separation is enabled if the user is also assigned to a second CA role. If the CA Administrator assigns himself or another role holder to a second role, then the CA Administrator violates the rules of role separation by allowing a user to have two roles. Once the user is assigned to two roles, role separation will not allow that user to perform any activity on the CA, including, in the case of the CA Administrator, the activity of removing himself from one of the roles.

To correct this configuration, the local Administrator of the server must disable role separation, remove the CA Administrator from the second role, and then restart the Certificate Services service. Following these steps, role separation can be enabled again.

Windows 2000 and Windows Server 2003 role-based administration

During the upgrade from a Windows 2000 CA to a Windows Server 2003 CA, Windows 2000 CA permissions are upgraded to Windows Server 2003 CA roles according to the rules listed in the following table.

Windows 2000 permission | Windows Server 2003 role or permission
Manage CA permission | CA Administrator and Certificate Manager
Revoke Certificate permission | Certificate Manager
Approve Certificate permission | Certificate Manager
Enroll permission | Enroll permission
Read permission | Read permission
All other permissions listed in the Windows 2000 CA advanced security settings. | Read permission

Note

  • Role separation is only available on servers running XOX and XOX, including the 64-bit version of XOX and 64-bit version of XOX. Role-based administration is available on servers running any version of the Windows Server 2003 family.


Establish the certificate types that an enterprise certification authority can issue

Microsoft Windows graphic

To establish the certificate types that an enterprise certification authority can issue

  1. Log on to the system as an Administrator.
  2. Open Certification Authority.
  3. In the console tree, right-click Certificate Templates click New, then click Certificate Template to Issue.

    Where?

    • Certification Authority (Computer)
    • CA name
    • Certificate Templates
  4. Select a certificate template to begin using for issuance.

Notes

  • XOX

Related Topics